


Ahogy azt ígértük... 

Megváltozunk. Ígérem. Na, nem úgy, 
ahogy Bajor Imre ígérte tíz éve egy 
kabaréban, hogy új életet kezd, de 
mivel a piát szereti, ezért az új életé- 
ben is inni fog. Mi inkább azon tulaj- 
donságainkat igyekszünk átmenteni, 
melyeket olvasóink is a lap értékének 
tartanak. 


Az elmúlt időszakban folytatott piac- 
kutatások és olvasói levelek alapján 
három főbb változási cél rajzolódott 
ki előttünk. Olvasóink szerint: 


e — A cikkek túl tömörek, nehezen 
olvashatóak 


e Kevés a kezdőknek, próbálkozó 
kedvűeknek szóló cikk 


e — Több hazai vonatkozású, olvasmá- 
nyos cikkre van igény 


A tervek megvitatása közben még egy 
gondolat folyamatosan felvetődött: 
valahogy jobban be szeretnénk vonni 
a hazai szakembereket a Linuxvilág 
szerkesztésébe. Ezzel egyrészt egy 
érdekesebb, színesebb anyag állhat 





össze, másrészt pedig lehetőséget is 
biztosítunk egymás megismerésére. 
Az új ,nyílt" szerkesztés jegyében 
kialakítottunk tehát egy weboldalt 
(5 linuxvilag.hu/szerzoknek), ahol 
bárki jelentkezhet, aki szívesen írna 
cikket, vagy elmondaná, hogy milyen 
cikket látna örömmel az újságban. 
A cikkírók itt további anyagot is 
találnak a leadandó cikkekkel kap- 
csolatban. 


Reményeink szerint a szeptemberi 
számtól már egy teljesen új arculattal 
indul, mindhárom célterületen változ- 
va, olvasóink igényéhez jobban alkal- 
mazkodva. Mint mindig, most is 
örömmel várunk bármilyen véle- 
ményt, ötletet, kritikát! 

A , mostani generáció" utolsó két lap- 
számához is kellemes olvasást kívánok! 


Szy György 
főszerkesztő 
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Kütyüimádóknak 

A Nokia újfajta, internet tábla névre 
keresztelt mobil eszközt mutatott be. 
A teljes nevén Nokia 770 Internet Tablet 





készülék internetezésre, elektronikus 
levelek kezelésére, médiafájlok megte- 
kintésére és lejátszására, RSS hírcikkek 
olvasására, internetes rádiózásra hasz- 
nálható. Operációs rendszere a nokiás 
hagyományokkal szakítva Linux alapú, 
kijelzője 800x480 képpont felbontású, 
a hálózathoz Wi-Fi és Bluetooth össze- 
köttetésen keresztül képes csatlakozni, 
az adatbevitelt pedig a képernyőn 
megjelenő billentyűzettel teszi lehető- 
vé. A tábla szoftverét a Nokia rendsze- 
resen frissíteni tervezi, az első megúju- 
lást jövő évre tervezik, amikor IP feletti 
hangtovábbítási és azonnali üzenetkül- 
dési képességgel ruházzák majd fel 

a készüléket. A sokoldalúsága ellenére 
inkább szórakoztató haszontalanság- 
nak tűnő tábla Amerikában és Európában 
a harmadik negyedévben jelenik meg, 
egyelőre ismeretlen áron. 
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Van képzeletük 

Az AMD véglegesítette és nyilvánosan 
is elérhetővé tette Pacifica virtualizációs 
megoldásának leírását. A célközönsé- 
get elsősorban a programozók alkot- 
ják, akik így talán kellő időt kapnak 
arra, hogy alkalmazásaikat képessé 
tegyék az először 2006 első félévében 
megjelenő AMD x86 processzorok által 
támogatott technológia nyújtotta lehe- 
tőségek kihasználására. A hardveres 
virtualizáció az AMD ígéretei szerint 

a kiszolgálókba és az ügyfélgépekbe 
szánt lapkák esetében egyaránt elérhe- 
tő lesz, bár használatához nem lesz 
elég új processzort vásárolni, új alap- 
lapra és lapkakészletre is szükség lesz. 
A fejlesztésnek további lendületet ad- 
hat, hogy Vanderpool néven, ugyancsak 
jövőre az Intel is hasonló képességek- 
kel fogja felruházni Itanium és Xeon 
processzorait, és a két megoldás nagy- 
mértékben hasonlítani fog egymásra. 
5 http:/www.xbitlabs.com/news/ 
video/display/20050519225638.html 
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Táblájuk még nem volt 

Az IBM PC-s üzletágát nemrég átve- 
vő Lenovo bemutatta az első ThinkPad 
tábla PC-t. Az IBM ThinkVantage meg- 
oldásait a terméksorozat egyéb tagja- 
ihoz hasonlóan támogató táblagép 
pontos jelölése ThinkPad X41 Tablet, 
alapjául az Intel Centrino platform- 
jának legújabb, Sonoma kódnevű 
változata adja. A gépbe alacsony 

és ultraalacsony feszültségű Intel 
processzorok és DDR2 RAM kerül, 
továbbá természetesen a 802.11 a/b/g 
csatoló sem maradhat el belőle. 

A 127-os kijelzőjű gép súlya 1,58 kg 
lesz, akkumulátoros üzemideje elvi- 
leg a 8,5 órát is elérheti majd. Operá- 
ciós rendszere a Windows XP Tablet 
PC Edition 2005 lesz, ára pedig 1899 
dollártól indul. 


Legközelebb milyen mosóport 
vásárol? 


A VeriFone beágyazott Linux multi- 
médiás PIN-táblát mutatott be. 





A készülék mostantól ősinek számító 
példányai mindannyiunk számára 
ismerősek az üzletekből: kártyás 
vásárlásnál ezt a kisméretű billen- 
tyűzetet nyomják a kezünkbe, 

hogy írjuk be a PIN-kódunkat, 

majd ,nyomjuk meg a zöldet". 

Az MX870 a kor színvonalának 
megfelelően támogatja a rádiós azo- 
nosítókat, az intelligens kártyákat 
és a biometrikus azonosítást, színes 
érintőképernyője pedig alkalmas 
arra, hogy a fizetéssel bíbelődő vá- 
sárlónak multimédiás hirdetéseket 
jelenítsen meg. Az élmény fokozását 
egy 5,77-es, 240 x 320 képpontos, 
65000 szín megjelenítésére képes 
kijelző, egy 200 MHz-es ARM pro- 
cesszor, valamint 16 MB RAM és 
32-128 MB Flash memória bizto- 
sítja - mindezekhez kiegészítő 
jelleggel beépített, térhatású hang- 
szórókat is lehet kérni. 
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Titkos biztonság 

Minden adatra kiterjedő, hardveres 
titkosítást végző, hordozható számító- 
gépekbe és külső meghajtókba szánt 
merevlemezt mutatott be a Seagate. 


Seagate LL 


We turn on ideas 


A szintén nemrég megjelent, 2,57-os 
Momentus termékcsalád 5400-as tagjai- 
ra épülő meghajtó a lemez egy elkülö- 
nített területén egy titkosító kulcsot 
tárol, ennek alkalmazásával minden 

a csatolófelületen keresztülhaladó 
adatot automatikusan, a felhasználó 
további beavatkozása nélkül titkosít. 
A kulcs megadása nélkül a lemezen 
tárolt adatokhoz még a meghajtó gép- 
ből való kiszerelésével sem lehet hoz- 
záférni, illetve az operációs rendszer 
elindítására sincs lehetőség. Az új 
meghajtóval elsősorban az üzleti fel- 
használókat célozzák meg, hiszen 

a vállalkozásoknak sokszor bizalmas 
adatokat kell hordozható gépeken 
tárolniuk, amelyek viszont erősen ki 
vannak téve az ellopás veszélyének. 
Természetesen az adatok titkosítása 
eddig sem volt megoldhatatlan fel- 
adat, ám azt általában szoftveresen 
vagy valamilyen kiegészítő eszközzel 
végezték; ez az első példa a titkosítási 
szolgáltatás merevlemezes meghajtó- 
ba építésére. Ha a megoldás sikeres- 
nek bizonyul, akkor elképzelhető, 
hogy hamarosan a Seagate egyéb 
termékeiben is megjelenik. 
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Csábító hangok 

Kifejezetten a Windows-felhasználók 
elcsábítására állította össze a Xandros 

a főként otthoni, egyszerűbb irodai 
feladatok ellátására szánt SurfSide 
Linuxot. A terjesztés tartalmaz vírus- 
keresőt és tűzfalvarázslót, lehet vele 
dokumentumokat szerkeszteni, DVD-t 
írni, fájlokat titkosítani és így tovább. 
Különlegessége, hogy nemcsak tar- 
talmazza a Skype internettelefon- 
alkalmazást, de a dobozos változathoz 
mellékelnek egy LISB-s Plantronics fej- 
beszélőt, valamint egy Skypeout kupont 
is, amivel a felhasználó 120 percnyi 
beszélgetést folytathat a világ bármely 
telefonszámára. A Xandros SurfSide 
Linux ára öt cent híján 100 dollár. 











Nyíltan, szépen 

Az OASIS (Organization for the 
Advancement of Structured Information 
Standards, szervezet a strukturált infor- 
mációs szabványok fejlesztéséért) bejelen- 
tette, hogy szabványként fogadta el 

az Open Document Format for Office 
Applications, röviden OpenDocument 
1.0-s változatát — ezt az XML alapú 
formátumot fogja alkalmazni az 
OpenOffice.org irodai csomag 2.0-s, 
hamarosan megjelenő változata is. 

Az új formátum, bár az OpenOffice 1.x 
formátumokra épül, azokkal nem 
kompatibilis, ugyanakkor tökéletesen 
nyílt, bármilyen irodai programcso- 
mag által használható, szövegek, táblá- 
zatok, grafikonok és grafikai anyagok 
tárolására egyaránt alkalmas. Érdemes 
megjegyezni, hogy a Microsoft Office 
következő változata is XML alapú for- 
mátumot fog használni, ám az ettől el- 
térő és részben zárt lesz, használatáért 
jogdíjat kell majd fizetni. Az új formá- 
tum mögött máris felsorakozott többek 
közt a Sun, az IBM és a Red Hat. 

A Siemens bejelentette, hogy eladja 

— egyébként masszívan veszteséges — 
mobiltelefon-üzletágát a tajvani BenO- 
nak, miközben 2,5 százalékos részese- 
dést is szerez benne. Az üzlet révén 

a Siemens megszabadul a pénznyelő 
ágazattól, a viszonylag kis, mindössze 
három éve létező BenO viszont a világ 
legnagyobb mobiltelefon-eladói közé 
nőhet fel. A BenO a megegyezés szerint 
még 5 évig használhatja a teleftonokon 
a Siemens nevet, illetve bizonyos sport- 
támogatói szerződéseket is átvesz. 

Az inkább az olcsó termékek szegmen- 
sében terjeszkedő BenO tempós fejlő- 
dést vár a mobiltelefonok területén, az 
első BenO-Siemens készülékek már ez év 
végén megjelenhetnek az üzletekben. 


Onállósodó Fedora 

A Red Hat önálló, független alapítványi 
feladattá tette a Fedora terjesztés gon- 
dozását. Bár ez egyfajta távolodást je- 
lent a cég részéről, szerencsére arról 
szó sincs, hogy a kalaposok levennék 
kezüket az ingyenes operációs rend- 
szerről, a lépés sokkal inkább a kódok 
szerzői és használati jogainak rendezé- 
sére irányuló lépésnek tűnik. A Red Hat 
terjesztések a Fedora tervezet keretein 
belül továbbra is elérhetők lesznek, 
ahogy az alapítvány a cég pénzügyi 

és műszaki segítségére is számíthat. 
Ugyancsak átadásra kerül például az 
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újonnan bemutatott címtárkiszolgáló 
és a hamarosan megjelenő tanúsít- 
ványkezelő rendszer is, a felhasználók 
mindkét programot GPL hatálya alatt 
érhetik majd el. Ide kapcsolódik a Red 
Hat Software Patent Commons kezdemé- 
nyezése is, melynek mintájául a grafi- 
kákat, hangokat, szövegeket összefogó 
Creative Commons gyűjtemény szolgált, 
és melynek célja segítséget nyújtani 

a szoftverszabadalmak használati joga- 
inak kezeléséhez, átadásához. A gyűj- 
temény életre hívása talán stratégiai 
húzás is, hiszen a Red Hat a jelenlegi 

— szerintük a nyílt forrású fejlesztéseket 
gátló — szabadalmi és szerzői jogi 
szabályok megváltoztatása mögé állt. 


Oracle? Mi az nekünk! 

Az EnterpriseDB Corporation kiadta 
EnterpriseDB 2005 adatbázis-kiszolgá- 
lójának béta változatát. A szabadon ki- 
próbálható csomag nyílt forrású prog- 
ramokra épül, konkrétabban az adat- 
bázis alapját a PostgreSOL adja, ennek 
továbbfejlesztésével a cég állítólag 
nagyvállalati szintű, az Oracle adatbá- 
zisokkal versenyképes, ám azoknál 
olcsóbb terméket tudott előállítani. 

Az Oracle-nek vetett kesztyű — bár 

a két cég viszonyát leginkább a bolha 
és az elefánt párharcához hasonlíthat- 
nánk - nem merül ki az ígérgetésben, 
az EDB2005 támogatja az Oracle alapo- 
kon fejlesztett alkalmazásokat, illetve 
az Oracle-téle SOL-szintaxist, adattípu- 
sokat, ravaszokat és natív tárolt eljárá- 
sokat, miközben általános körülmé- 
nyek között gyorsabbnak ígérkezik 

a hasonló nyílt forrású termékeknél. 
A különféle terjesztésekhez jelenleg 
szabadon letölthető csomagban az 
adatbázis-kezelő motor mellett egy 
grafikus felhasználói és rendszergaz- 
dai konzol, továbbá JDBC, ODBC, 
.NET, ESOL/C4-3-, PHP, Perl és Python 
csatlakozók találhatók. A cég idén 
nyáron végleges változatban is, egy- 
előre ismeretlen áron megjelenő rend- 
szerével az ingyenes, de kis tudású és 
a komoly tudású, de drága termékek 
közé szeretne beékelődni a piacon. 

3 www.enterprisedb.com 


Medgyesi Zoltán 
(mz€rettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Mi újság a rendszermag fejlesztése körül? 


A iswraid illesztőprogram jó úton halad afelé, hogy 
a 2.4-es fa részévé váljon, annak ellenére, hogy 
újabb szolgáltatásokkal bővít egy üzembiztos soro- 
zatú rendszermagot. Marcelo Tosatti végül Jeff 
Garzik mellé állt e kérdésben, dacolva számos más 
fejlesztő ellenvéleményével. Jeff úgy érvelt, hogy az 
iswraid nélkül a 2.4-es használói nem tudják majd 
beüzemelni új hardvereszközeiket, míg az ellenzők 
(köztük Arjan van de Ven, Bartlomiej Zolnierkiewicz 
és Christoph Hellwig) rámutattak, hogy pontosan 
ugyanez történik minden más hardverrel is, aminek 
még nem oldódott meg a támogatása. A jelenlegi 
helyzet szerint Jeff feladata a kérdés rendezése, 
vagyis az iswraid szerepelni fog a 2.4 jövőbeli 
kiadásaiban. 

Számos új illesztőprogram látott napvilágot. Vojtech 
Pavlik például készített egy a soros £/o érintőképer- 
nyők támogatására alkalmas illesztőprogramot, 
amely az összes soros £E/o-t ismeri. A rendszermag- 
nak ez a területe egyelőre még nem bontakozott ki, 
ugyanis, bár az érintőképernyők támogatására eddig 
is láthattunk példákat, azok inkább belső, vállalati 
tervezetek keretében valósultak meg. Új valós idejű 
óra illesztőprogram készült az ST M4ATTOO I2C RTC 
lapkához; Mark A. Greer szerzeménye gyakorlatilag 
készen áll arra, hogy a 2.6-os fa részévé váljon. 
Mark a PPC és MIPS rendszerekben található 
Marvell gazdahíd /2C vezérlőjéhez is készített egy 
illesztóprogramot. 

Willy Tarreau — Marcelo Tosatti áldásával — új gyors- 
javítási ágat indított a 2.4-es fán belül. A -hf ág 
ugyanazokat a javításokat fogja tartalmazni, mint 

a 2.4-es, ám rövidebb megjelenési időkkel készül. 

A -hf ág az új illesztóprogramokat és a meglévő 
illesztóprogramok frissítéseit nem fogja tartalmazni, 
kizárólag biztonsági és a kód letisztulását szolgáló 
javításokat foglal majd magába. Magától értetődő 
kérdés, hogy a -hf ág elindítása előtt maga Marcelo 
is megfontolhatta volna a kiadások felgyorsítását. 

A helyzet az, hogy a kialakult megoldás összhang- 
ban volt Marcelo azon szándékával, hogy a 2.4-es 
rendszermagot inkább az üzembiztosság irányába 
terelje, amivel viszont semmiféle kapkodás nem 
egyeztethető össze. 

Christoph Lameter scrubd névvel készített egy 
lapnullázó démont, illetve összeállította a haszná- 
latához szükséges rendszermagbeli környezetet is. 
Célja az, hogy a lehető legjobb teljesítményt le- 
hessen kihozni a laphibakezelőből, segítségével 

a memórialapok nullázása még használatba véte- 
lük előtt megtörténik, nemcsak akkor, amikor 

egy folyamat kéri őket. Szép dolog még az ilyen 
aprónak tűnő fejlesztésekre is figyelmet fordítani. 
Nem egy új illesztőprogramról van szó, semmilyen 
API módosítását nem igényli, sőt, a külvilág 
számára gyakorlatilag észrevehetetlen, mégis 


hozzájárul ahhoz, hogy a Linux kifinomult, kiváló, 
mindannyiuk igényeinek megfelelő operációs 
rendszerré váljon. Pontosan ezek az optimalizálá- 
sok adják a Linux színe-javát, és megérdemlik, 
hogy az új illesztőprogramok és a különleges 
fájlrendszerek mellett említsük őket. 

Az out-of-memory process killer (DOM Killer, 
,memórián kívüli folyamatok gyilkosa") továbbra is 
az egyik legkeményebb dió a Linux fejlesztésében. 
Mauricio Lin nemrég kiadott egy felhasználói térben 
futó változatot, amely állítása szerint ugyanolyan jól 
működik, mint a rendszermag térben futó. A kérdés 
azonban sajnos nem ilyen egyszerű. A felhasználói 
térben futó eszköz ugyanis legalább annyira esélyes 
a memórián kívüli állapotba kerülésre, mint az 
összes többi program. Ugyanakkor a rendszermag 
oldali OOM Killert sokkal nehezebb az egyes rend- 
szerek egyedi jellemzőinek megfelelően hangolni. 
Mauricio egyfajta kompromisszumot kötött azzal, 
hogy az osztályozó algoritmust a felhasználói térbe 
helyezte, ahol könnyebben lehet módosítani a beállí- 
tásait, magát a gyilkost azonban a rendszermagban 
hagyta, ahol védettebb az éppen általa vadászott 
memórián kívüliségtől. Bár az egész problémát 
rendkívül nehéz megfelelően kezelni, az OOM- 
kezelő eszközök ugyanis mindig bonyolultak, 
Mauricio megoldása a vezető fejlesztők között is 
támogatásra lelt, például Marcelo Tosatti részéről. 
Mauricio a témához kapcsolódó területeket is körbe- 
járta, nemrég például olyan foltot készített, amely- 
nek segítségével a felhasználók a /bProc könyvtárban 
figyelemmel követhetik a folyamatok fizikai memó- 
riahasználatát. Mondani sem kell, ennek kapcsán is 
voltak viták, ám Andrew Morton támogatja a dolgot, 
és mások is felvetettek olyan alkalmazási lehetősé- 
geket, amelyek a gyakorlatban is hasznossá teszik 
a szolgáltatást. 

Jeff Garzik nemrég felhívást tett közzé, mely szerint 
több félbehagyott, hibás illesztőprogramot kell 
hamarosan eltávolítani a 2.6-os fából. Az iphase 
illesztőprogram például már évek óta gazdátlan, 
mára már a lefordítása is lehetetlenné vált. 

A xircom tulip cb illesztőprogramot senki sem tartja 
karban, ráadásul nem ismeri az összes 32 bites 
Xircom kártyát. A xircom cb illesztőprogram ellen- 
ben igen, vagyis kiváló helyettesítőt jelentene. 

A eepro10Oo illesztőprogram szintén magára maradt, 
szerepét az e100 veszi át. Szerencsére azoknak 

a felhasználóknak sem kell izgatniuk magukat, akik 
az e100-at valamiért nem tudják használni, ugyanis 
a felmerült hibákat még az eepro100 eltávolítása 
előtt el fogják hárítani. 


Zack Brown 
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SUSE Linux Professional 9.3 
A Novell kiadta a SUSE Linux 
Professional 9.3-at, mely teljes 
értékű operációs rendszert, 
több mint háromezer nyílt forrá- 
sú csomagot, több száz nyílt 
forrású alkalmazást és termelé- 
kenységnövelő programokat 
foglal magába, illetve támogatja 
az otthoni hálózatokhoz szánt 
szolgáltatásokat is. Az újoncok 
és a régi Linux-felhasználók 
számára egyaránt jól használható 
SUSE Pro 9.3 számos újdonsá- 
got tartalmaz. Az operációs 
rendszer a 2.6.11-es rendszer- 
magra épül, mely köré KDE 
3.4-et és GNOME 2.10-et, 
Firefox 1.0-t, OpenOffice.org 
2.0-t, F-Spot fényképszervezőt, 
The GIMP 2.2-t, Mono 1.1.4-et, 
KDevelop 3.2-t, Eclipse 3.0. 1-et 
és továbbfejlesztett Vo/P- 
támogatást tartalmazó program- 
csomagot állítottak össze. 

A SUSE Pro 9.3 a Wi-Fi kap- 
csolatok és a Bluetooth készü- 
lékek magasabb szintű támo- 
gatásával, a zsebtitkárokkal és 
telefonokkal végzett szinkronizá- 
lás lehetővé tételével, az iPod 
készülékek támogatásával, 
beépített tűzfallal, levélszemét- 
szűrővel és víruskeresővel, 
továbbá Novel/ Evolution 2.0-val 
és Kontact 3.4-el segíti a fel- 
használókat mobilitásuk meg- 
őrzésében. A 9.3-mas kiadás 
ezek mellett tartalmazza a XEN 
virtualizációs környezetet, a kere- 
sésekben könnyen használható 
motorokkal segíti a felhasználó- 
kat, illetve egyaránt támogatja 
az AMD Athlon 64-et és az 

Intel Extended Memory 64 
Technology-t. 

www.novell.com 


OPTIion 


Az OPTIion egy képzetes vékony 
ügyfél linuxos munkaállomások- 
hoz. GNOME és KDE alatt egy- 
aránt használható, egyetlen al- 
kalmazáson keresztül az összes 
ismertebb ingyenes vagy keres- 
kedelmi terminálkiszolgáló kör- 
nyezet elérését lehetővé teszi. 
Minden ügyfélkapcsolat beállítá- 
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sa és felügyelete központilag 
örténik, és minden feladat meg- 
jelenítése és futtatása egy köz- 
ponti keretrendszerben folyik. 

A támogatott ügyfélkapcsolatok 
között szerepel az XDMCP, teljes 
képernyős és/vagy ablakos mód- 
ban; a biztonságos és közvetlen 
X; a biztonságos X bejelentke- 
zés, teljes képernyős és/vagy 
ablakos módban; az ADP, szin- 
tén teljes képernyős és/vagy 
ablakos módban; az xRDP, 
beépített Ericom modullal, 

mely lehetővé teszi az észre- 
vétlen együttműködést a WTS 
2000/2003-mal, illetve ingyenes 
RemoteView terminálkiszolgáló- 
ügynököt biztosít; az /CA, kiszol- 
gáló- és alkalmazásböngészővel; 
az Ericom PowerTerm Emulator 
csomag; a NoMachine NX 
Client, mely az NX Server 1.3 és 
1.A támogatására képes; illetve 
a natív Tarantella. A támoga- 

tott Linux-terjesztések körét 

a MandrakeLinux, a Fedora, 

a Novell/SUSE és a Xandros 
alkotja. 

www.smartflextech.com 


ConvertX SDK 


A Plextor Corporation bejelentette 
egy szabadon hozzáférhető, 
a ConvertXx videórögzítő eszközök- 








höz készült linuxos szoftverfej- 
lesztő készlet elérhetőségét. 

A készlet segítségével az USB 2.0 
felületre csatlakozó, hardveres 
MPEG-1, MPEG-2, MPEG-4 és 
Motion JPEG tömörítésre ké- 

pes Plextor ConvertX személyi 


videófelvevő készülékekhez 

lehet alkalmazásokat készíteni. 

A linuxos fejlesztői készlet támo- 
gatja a Video for Linux 2 (V4L2) 
és az Advanced Linux Sound 
Architecture (ALSA) előírásait. 

A ma már elavultnak számító 
Open Sound System (OSS) alapú 
alkalmazások támogatását az 
ALSA által biztosított OSS együtt- 
működési réteg révén teszi lehe- 
tővé. Az új illesztőprogram, mely 
immár 2.6-os rendszermagot igé- 
nyel, nyílt és zárt alkalmazások- 
ban egyaránt felhasználható kód- 
részleteket tartalmaz, ezek alapján 
a fejlesztők remélhetőleg 
könnyebben el tudnak indulni 
munkájukkal. 

www.plextor.com 


ARCOS 4.0 

A Plus Three, LP kiadta az 
ARCOS 4.0-t -— az alkalmazás 
Linuxra, Apache-ra, MySOL-re 
és Perl-re épül, célközönségét 
az adománygyűjtő szervezetek 
adják. Az ARCOS alkalmas a tá- 
mogatókkal kiépített kapcsolatok 
kezelésére, az elektronikus leve- 
lek és a kapcsolattartások köve- 
tésére, az eseménykezelésre, 

a csoportos kapcsolattartásra, 
illetve internetes , tevékenység- 
központ" fenntartására. Új szol- 
gáltatás a továbbfejlesztett valós 
idejű jelentéskészítés az adatbá- 
zisok alapján, a nagyvállalati 
szintű biztonsági mentés, illetve 
a nagyobb és gyorsabb felhasz- 
náló-adatbázis. Az ARCOS elekt- 
ronikus hírlevél moduljával a fel- 
használók számtalan különböző, 
az adatbázisban tárolt szempont 
szerint állíthatják össze a e-mail 
címlistákat. A webes közzétételi 
modul testreszabható támogatói 
oldalak létrehozását és , mondd 
el a barátodnak" oldalak létreho- 
zását is lehetővé teszi. Emellett 
az e-mail és a webes közzétételi 
modulokat összeépítették, így 

a felhasználók óránként akár 
kétmillió üzenet feldolgozását 

is elvégezhetik. 
www.plusthree.com 
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A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 

útmutatásokat a 

Dwww.linuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 

válaszokat Linux-szak- 
értők kis csapata készí- 
tette el. További kérdé- 
seiteket szívesen fogad- 
ják (angol nyelven) a 
Dwww.linuxjournal.com/ 
[/-issues/techsup.htmli 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a bis(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a ,BIS" 
kulcsszó. 
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A hónap szakmai tanácsai 


Nagyméretű meghajtók? 

Red Hat 9.0, Fedora 1 és Debian 3.Or4 rendszereket 
használok. Segítséget kértem az Inteltől a 160 GB-os 
merevlemezek használatával kapcsolatban, de ők azt 
válaszolták, hogy a lehetőségeket az operációs rend- 
szer határolja be. Utána a Windows 2000-re és 

a Windows XP-re utaltak, ezért arra gondoltam, talán 
a BIOS is szerephez juthat. Mit gondoltok a témáról, 
és vajon hol találhatnék további anyagokat róla? 
Georg Robertson 

2 grobertson29oearthlink.net 


A gép BIOS-a valóban korlátozza, korlátozhatja 

a merevlemezek méretét. A jó öreg DOS Int 13 eljá- 
rása nagyjából 8 GB-ban szabta meg a meghajtók 
maximális kapacitását, míg a korszerű BIOS-ok és 
merevlemezek képesek a 32 bites szektorcímzésre, 
amivel több mint 2 TB az elméleti határ — ez persze 
új kihívásokat jelent a szoftverek számára. Mind- 
emellett az operációs rendszer lemez-illesztő- 
programjai, rendszertöltője, fájlrendszere és egyéb 
szolgáltatásai — például szoftveres RAID — szintén 
befolyásolhatják a lemezmeghajtók vagy meghajtó- 
csoportok kihasználható kapacitását. 

Felipe Barousse Boué 

2 fbaroussegpiensa.com 


Én sokszor dolgozom furcsán formázott, általában 
windowsos meghajtókkal; szerencsére a rendszer- 
magnak kézzel is meg lehet adni, hogy mit kezdjen 
velük. A témakörhöz készült egy kiváló útmutató, 
javaslom, hogy kezdésként ezt tanulmányozd át: 
www. tldp.org/ HOWT O/Large-Disk-HOWVTO. html. 
Chad Robinson 

5 chadeOlucubration.com 


Mobiltelefon használata USB kábelen keresztül? 
Több GPRS mobilt is tudtam már használni, köztük 
Motorola V66-ot és Timeportot, de csak soros kábe- 
len keresztül. A legújabb GPRS mobilok azonban 
már csak USB-s adatkábellel rendelkeznek. Próbál- 
tam az egyiket Linux alatt használni, de mindhiába, 
a számítógép nem találta meg a modemet. Tudtok 
valamit javasolni? Vajon hol találok megfelelő 
illesztóprogramokat? 

2 kimayavsnl.com 


Ezek az eszközök szinte mindig sorosak, csak tartal- 
maznak egy az USB felületet biztosító USB-soros át- 
alakító lapkát. Az átalakítás kétféle módon történhet. 
Az egyik megoldásnál, ilyen például az FTDI lapka- 
készlet, egy virtuális soros kapu jön létre az USB fe- 
lületen keresztül. Ezeket a termékeket már támogat- 
ja a Linux, de ha mégse, akkor csupán idő kérdése, 
hogy a dolog rendeződjön. 





A második csoportba a zárt fejlesztések tartoz- 
nak, ezeknél egyedi illesztőprogramok tartják 

a kapcsolatot a távoli lapkakészlettel. Itt már 
bajosabb a hordozhatóság, hiszen a gyártók 
jellemzően csak Windows alá készítik el az 
illesztőóprogramokat, amelyek nélkül persze 

nem lehet adatkapcsolatot létesíteni az eszközzel. 
Szerencsére ezekből egyre kevesebb van, bár 
sajnos az ilyen megoldások olcsóbbak, mint 

a virtuális kapukat létrehozó lapkakészletek, 

ezért teljes eltűnésük sem várható. A legjobb 

az, ha a hírcsoportok, fórumok és egyéb források 
segítségével tájékozódsz, utánaolvasol, hogy má- 
soknál mi működik és mi nem, és elkerülöd az 
ilyen termékeket. 

Chad Robinson 

2 chadelucubration.com 


Számtalan GPRS telefon használható Linux alatt; 
a következő webhelyeken rengeteg hasznos infor- 
mációt találsz a témával kapcsolatban: 


kotinetti.suomi.net/mcfrisklinux gprs.html, 
users.tkk.fi/kehannin/bluetooth/bluetooth.html és 
markus.wernig.net/en/it/usb-serial-handy-ppp.phtml. 


Javaslom, hogy a telefon és a Linuxot futtató gép 
közötti kapcsolat létrehozását Bluetoothon keresztül 
is próbáld meg - természetesen ehhez megfelelő 
csatoló és Bluetooth-képes telefon kell. 

Felipe Barousse Boué 

2 fbarousseOpiensa.com 


A Tuxmobil.org webhelyen szerepel egy lista 

a működőképesnek bizonyult összeállításokról, illet- 
ve útmutatást is találsz az egyes telefonmodellek 
használatához. 

Don Marti 

2 dmarti€ossc.com 


Hibajelzés a MYySOL ügyféltől 

A Fedora Core 3 grafikus MySOL ügyfélprogramját 
próbálom használni, de állandóan összeomlik, 

a következő üzenettel: 


[anupamalocalhost mysglgui-1.7.5-1-1]inux- 
s static]$ ./mysalgui 

mysalgui: dynamic-Tlink.h:57: 

self get dynamic info: 

Assertion ! "bad dynamic tag"" failed. 
Aborted 


Vajon mi a baj? 
Anupam De 
5 anupamosail-steel.com 
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A mysgliguit binárisan töltötted le, vagy szöveges 
vagy ASCII módban? Ha ugyanis szöveges vagy 
ASCII módban töltötted le, akkor valószínűleg meg- 
sérült a fájl. A félig statikus bináris fájl helyett pró- 
báld meg a statikusan fordított változatot letölteni. 
Így a függőségek túlnyomó részével nem kell foglal- 
koznod, ugyanis a — valamivel nagyobb - futtatható 
fájl minden szükség elemet tartalmaz. 

Felipe Barousse Boué 

5 fbarousseDpiensa.com 


Soros kapuk IRO-inak megadása 

Win4Lin-t futtatok SUSE 9.2 alatt, és keményen küz- 
dök a 2-es COM kapu IRO-jának megváltoztatásával. 
A Windowsra egy energiafelügyeleti program miatt 
van szükségem, ami külső hívásokkal ellenőrzi több 
épületbéli rendszer állapotát is. A Linux 10-es IRO-t 
állított be, de 4-nek kellene lennie. Meg tudjátok 
mondani, hogyan változtathatom meg az IRO-t? 
John Langston 

2 jdl.280cox.net 


Az IRO-t a BIOS beállításai között kell megváltoztat- 
nod. Ha nem sikerül, akkor használd a linuxos 
setserial segédprogramot. 

Greg Kroah-Hartman 

D gregeokroah.com 


A segédprogram kapcsolóit a man setserial pa- 
ranccsal tekintheted át. Ne feledd, ha a fizikai soros 
kapuk fix IRO-val és/vagy memóriacímmel rendel- 
keznek, akkor a setserial használatakor és/vagy más 
eszközök beállításainak módosításakor ütközéseket 
okozhatsz. 

Felipe Barousse Boué 

2 fbaroussepiensa.com 


Működésképtelen GigaDrive 

Nemrég vettem egy Linksys GigaDrive-ot az eBayen. 
A készülék látszólag működik, legalábbis bekapcsol, 
de az alkalmazások egyikét sem tudom elérni vagy 
futtatni. Arra gondoltam, talán megformázták vagy 
kicserélték a meghajtót, ezért újra kellene telepíteni 

a linuxos rendszert és az alkalmazásokat. Tudtok vala- 
milyen tanácsot adni a művelet elvégzéséhez, azon 
túl, hogy küldjem vissza a Linksysnek? Van ugyan A-t 
vizsgám, de linuxos tapasztalatom nem nagyon. 
Talán, ha sikerülne szereznem egy telepítő CD-le- 
mezt, akkor életet tudnék lehelni a gépbe, nem? 
Egyelőre a CD beszerzését sem tudom, hol kezdjem. 
Van valami ötletetek vagy javaslatotok? 

Randy Warner, 5 warn4421Obellsouth.net 


A Linksys webhelyén van egy oldal, ami ismerteti 
a GigaDrive belső programjának feltöltését: 





www.linksys.com/support/support.asp?spid- 17 


Ha ezzel nem jutsz előbbre, esetleg próbáld meg- 
szerezni egy jól működő, azonos méretű lemezt tar- 
talmazó GigaDrive merevlemezét, majd szereld be 
mindkét meghajtót egy linuxos gépbe. A működő 
meghajtó legyen a második IDE csatoló mester 
meghajtója, a nem működő pedig a szolga; majd 
add ki a következő parancsot: 


dd if-/dev/hdc 
Don Marti 
D dmarti€ossc.com 


o0f-/dev/hdd 


Kettős rendszerindítású gép mentése 

Jelenleg Microsoft Windows XP Professional operá- 
ciós rendszert használok, de ha sikerült megismer- 
kednem a használatával és felügyeletével, szeretnék 
áttérni Linuxra. Jelenleg a System Works 2004-ben 
található Norton Ghostot használom mentésre. 


Feltelepítettem a Fedora Core 1-et, ugyanis ez volt 
az általam megvásárolt könyvhöz mellékelve. A tele- 
pítés gond nélkül lezajlott, amit kaptam, az tetszett. 
Csakhogy, amikor a Ghostot akarom használni, és 
ezért visszaváltok Windowsra, a Ghost a következő 
hibaüzenetet adja: 


Biztonsági mentési hiba. Nincs hely az MBRh-ben. 


Gondoltam, hagyom a Nortont, majd Linux alól el- 
végzem a mentéseket - de vajon melyik programot 
használjam? Ti mit ajánlotok? 

Lev Ranara 

2 pinoy techiegyahoo.com 


Linux alatt általában egyszerű a mentések elvégzé- 
se. A Windowszal ellentétben nincsenek különleges 
rendszeradatok (mint például a rendszerleíró adatbá- 
Zis), amelyeket hagyományos eszközökkel nem le- 
het menteni. Egy teljes mentés sok esetben egy 
egyszerű fájlmásolással letudható, hacsak nem fut- 
tatsz adatbázis-kiszolgálót. Ha mégis, akkor a men- 
tés idejére azt le kell állítanod. 


Összetettebb megoldásokból is van bőven, ezekkel 
felügyelt, katalógusszerű mentéseket lehet végezni, 
illetve az egyes fájlok önálló visszaállítására is bizto- 
sítanak lehetőséget. Egy részük ingyenes (mint pél- 
dául az Amanda és a Bacula), másokat hagyomá- 
nyosan windowsos mentési programokat készítő 
cégek kínálnak ( VERITAS, CA stb.), megint másokat 
pedig kifejezetten linuxos megoldásokat fejlesztő 
cégektől (mint például a BRU) vásárolhatsz meg. 
Ha most Ghostot használsz, akkor vélhetően nem 
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fájl alapú mentéseket készítesz. A legegyszerűbb 
megoldás talán egy tömörített tar archívum létreho- 
zása lenne. A teljes rendszer visszaállításához ekkor 
elég lenne megadni a lemez felosztását, megfor- 
mázni a meghajtót, kibontani az archívumot majd 
telepíteni a rendszertöltőt. 


Ha helyes a gondolatmenetem, akkor talán kezdd 
a tar megismerésével; majd kiderül, hogy megfelel- 
e az igényeidnek. A... 


tar -jlcvf /tmp/mentes.tgz /bin /boot 
5 /dev /etcN 


parancs például a legtöbb esetben megfelelő. 
Kiadása után a létrejövő /tmp/mentes.tgz fájlt 
egyszerűen másold CD-lemezre, szalagra vagy 
egy fájlkiszolgálóra. Ha gondolod, a tar állományt 
közvetlenül a szalagon is létrehozhatod. 

Chad Robinson, 5 chadOlucubration.com 


Tapasztalataim szerint a linuxos világban a legjobb 
megoldás mentések készítésére a jó öreg tar pa- 
rancs használata. Szóba jöhetnek még más tömörí- 
tőprogramok is, mint a zip és a bzip; az egyedi igé- 
nyeimre pedig írtam néhány parancsfájlt. Megbízha- 
tó, hordozható, egyszerű és ingyenes — mondhatni, 
a szabad és anyagiak terén tudatos felhasználó vá- 
lasztása. A Linux alatt végzett biztonsági mentések 
témakörében mindent megtalálsz a www. linux- 
backup.net webhelyen. A Unix Backup and 
Recovery című könyv szintén ezzel a témával foglal- 
kozik, a www. linuxjournal.com/article/3839 címen 
rövid áttekintést is találsz róla. 


Mivel az FC1 mára elavulttá vált, próbálj FC39-at 
telepíteni. Az FCXx terjesztések számtalan tetszetős 
megoldást tartalmaznak, ezek közül például a kat- 
tints és húzd módban végezhető CD-írás mentési 
célokra is alkalmazható. 

Felipe Barousse Boué 

29 fbarousseDpiensa.com 


Az ügyfél csatlakozik, az átvitel mégis sikertelen 
Egy TFTP-kiszolgálót próbálok üzembe helyezni, de 
nem járok szerencsével. A helyzet röviden a követ- 
kező. Fedora Core 3-at futtatok egy Plll-as gépen. 
Telepítettem az rpmfind.net oldalon talált legújabb 
tftpd-t, majd megadtam a -— gondolom - megfelelő 
beállításokat az xinetd/in.tfptd fájlban. Egy másik 
linuxos gép tftp-ügyfelével ugyan sikerül csatlakoz- 
nom a kiszolgálóhoz, ám az olvasási kérés már meg- 
válaszolatlan marad. Az ügyfél többször is próbálko- 
zik, majd időtúllépést jelez. A varfog/xinetd fájlban 
minden az ügyfél által elküldött olvasási kérés hatá- 
sára a következő bejegyzések jelennek meg: 





05/3/16014:11:14: FAIL: tftp address 
5 from-153.90.196.30 

05/3/16014:11:14: START: tftp pid-20184 
5 from-153.90.196.30 

05/3/16014:11:14: EXIT: tftp pid-20184 
5 duration-0(sec) 


A kiszolgálón a következőket végeztem el. Létrehoz- 
tam egy tftp felhasználót, a kezdőkönyvtára 

a /tftpboot lett, majd lefuttattam a /sbin/nologint. 

A /etc/hosts. allow fájlhoz hozzáaádtam az 
in.tftpd:ALL bejegyzést. Létrehoztam a /tfipboot 
könyvtárat, és megadtam hozzá a megfelelő enge- 
délyeket és tulajdonosi beállításokat. Létrehoztam 

a /etc/xinetd.d/tftp fájlt a következő tartalommal: 


service tftp 


í 
disable - no 
socket type Stdggam 
protocol SAÜdb 
wait z yes 
user SüGO0G 
server S/usr/sbanzünátstpa 
server. args — -s /tftpboot -u tftp 
per. source szelő! 
cps SALO 
flags - IPv4 
fonly from SASZEGVELOSÉSŰ 
b 


Az only from sort megjegyzésbe tenni és onnan ki- 
venni is próbáltam. Ellenőriztem, hogy a tűzfal enge- 
délyezi-e a 69-es UDP- és TCP-kapu használatát. 

A /etc/xinetd.conf tartalma helyes, a chkconfig-gel 
ellenőriztem, a tfptd valóban fut. A netstat szerint 
a 69-es kapu elérhető. Az in.tftpd-t önálló kiszolgáló- 
ként is megpróbáltam futtatni (server args - -1). 


A dologgal már napok óta szenvedek, de nem sike- 
rül egyről a kettőre jutnom. A Linux világában még 
viszonylag új vagyok, megkértem néhány tapasztal- 
tabb ismerősömet, hogy nézzék meg a rendszert, 
de hiába. Az interneten is órákat kutattam már, de 
nem sikerült rájönnöm, mi a megoldás. Remélem, 
ti végre meg tudjátok mondani, merre induljak el. 
Todd Trotter, ishamtwesus.cs.montana.edu 


Úgy tűnik, majdnem mindent jól csináltál — de csak 
majdnem. Először is, a /etc/xinetd.d/tftp fájlban 

a felhasználót írd át nobody-ra, egyébként az in.tftpd 
démon rootként fog futni, ami nem biztonságos. 
Ezután ellenőrizd, hogy a 


SAL 69/tcp 
EPtD 69/udp 
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sorok nincsenek-e megjegyzésbe téve a /etc/services 
fájlban. Javaslom, hogy a /etc/hosts.deny fájlt is nézd 
át, nincsenek-e letiltva az in.tftpd démonnak intézett 
kérések, esetleg az összes szolgáltatás vagy adott 
IP-cím (ügyfélgép) kérései. 


A tesztelés idejére — de kizárólag ekkor - ki is üríthe- 
ted a fájlt, indítsd újra az xinetd-t (service xinetd 
reload), majd próbálkozz újra. Szintén a tesztelés 
időtartamára megpróbálkozhatsz a tűzfalad (servi- 
ce iptables stop) leállításával. A próbálgatás 
során először a helyi működést kell elérni, vagyis 

a tftp localhost parancs használhatóságát, 

a távoli elérés csak ez után következhet. Remélem, 
segítettem. 

Felipe Barousse Boué 

2 fbarousseDpiensa.com 


A szemétgyűjtés volna a válasz? 

Az újságban olvastam a szemétgyűjtésről. Van 
egy gondom, hadd írjam le röviden. Kezdetben 

a tervezet 192 MB memóriát foglal. A futása folya- 
matos. 12 óra után a memóriahasználat 335 MB-ra 
nő. Mi lenne a megoldás? A szemét miatt van ez? 
A BDW szemétgyűjtővel megoldódna a gondom? 
A tervezet char mutatókat tartalmaz, mal loc 
hívásokat viszont nem. 


A BDW szemétgyűjtés csak akkor működik, ha 
malloc, calloc és realloc hívásokat alkalmazok? 
Létezik olyan program, amit a saját tervezetemmel 
párhuzamosan futtatok, és felszabadítja a feleslege- 
sen lefoglalt memóriát? 

Mythily J. 

D mattuvargyahoo.co.in 


Utolsó kérdésedre a válasz: nem. Hacsak nem vala- 
mi szövevényes, túlbonyolított rendszerről van szó, 
kizárólag a saját programod tudja felszabadítani 

a saját maga által lefoglalt memóriát. 


A többi kérdésed valóban jó, csak azt tudom mon- 
dani, hogy amint kipróbálod az ötleteidet, azonnal 
megkapod kérdéseidre a választ. Lehet, hogy bár 

a malloc függvénycsaládot nem használod, mégis 
indítasz olyan könyvtári hívásokat, amelyek memóri- 
át foglalnak le, majd elhagyod azokat, amelyek fel- 
szabadítanák ezt a területet. 


A jó hír az, hogy a programodból készíthetsz olyan 
változatot is, amely a mal loc-ra ,ráakaszkodva" min- 
den memóriakezelő műveletnél szemétgyűjtést 
használ, ide értve a könyvtári kódok által végzett 
memóriafoglalásokat is. Példaként lásd a következő 
cikkben szereplő kódrészletet: 





www.linuxjournal.com/article/5679 


Don Marti 
D dmarti€ossc.com 


A futási szint módosítása 

A 2005. májusi szám szakmai tanácsaiban, 

a ,Régi Red Hat" című részben Timothy Hamlin 

a /etc/nittab bejegyzésének módosítását javasolja, 
a következőről 


x:5 : respawn : /etc/xX11/prefdm -nodaemon 
erre: 
x:3:respawn: /etc/XxX11/prefdm -nodaemon 


A módosítással elvileg kikapcsolható az X alapú, 
grafikus bejelentkezés. Azt hiszem, itt becsúszott 
egy hiba. Az általa javasolt módosítás után az X 3-as 
futási szinttel indul el. Helyette a következőt kellene 
megváltoztatni: 


id:5:initdefault: 
erre: 
id:3:initdefault: 


Ezzel valóban az alapértelmezett futási szintet 
változtatjuk meg. 


Az ,A fájlleírók és a blokkméretek módosítása" 
című részben Don Marti pedig arra utal, hogy 

a Red Hat 9 támogatása megszűnt, ami a régebbi, 
486-os gépek esetében gondot jelenthet. Nos, en- 
nél sokkal nagyobb bajt jelent a Red Hat által igé- 
nyelt memória mérete. Nem vagyok biztos abban, 
hogy 32 MB RAM-mal hajlandó települni; legalább- 
is 16 MB-tal biztosan nem telepíthető, ennyi volt 
ugyanis a jó öreg 486-os, hordozható gépemben. 
Roland Roberts 

5 rolandgastrofoto.org 


Az inittab mindkét módosítása megfelel a célnak. 
A másodiknak megvan az az előnye, hogy megőrzi 
a Red Hatféle hagyományt, mely szerint az 5-ös 
futási szint a grafikus bejelentkezéshez tartozik. 

A Fedora kibocsátási tájékoztatója szerint 
(fedora.redhat.com/docs/release-notes/fc3/x86) 

a minimális, szöveges telepítéshez legalább 
Pentium processzor és 64 MB memória szükséges. 
(Alternatív megoldást az utolsó levélnél találsz.) 
Don Marti 

2 dmarti(ossc.com 
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Na és a Fedora Legacy? 

A 2005. májusi szakmai tanácsok között Don Marti 
azt írja: , em a Red Hat 9-hez, sem a Red Hat 6.2- 
höz nincs már támogatás, vagyis nem adnak ki hoz- 
zájuk biztonsági frissítéseket." Bár a Red Hat való- 
ban felhagyott a Red Hat 9 támogatásával, a közös- 
ségi Fedora-Legacy tervezet 

(www. fedoralegacy.org) továbbra is készít biztonsá- 
gi frissítéseket a Red Hat 9-hez, ahogy a Red Hat 
7.3-hoz, valamint a Fedora Core 1-hez és (hamaro- 
san) a 2-höz is. Marti úr elég sokat ártott a tervezet- 
nek azzal, hogy egyszerűen figyelmen kívül hagyta 
az annak keretein belül történő erőfeszítéseket. 
John Dalbec 

2 jdalbec-ocboss.com 


Amikor nyomdába adtuk a lapot, a Fedora Legacy 
még nem kezdte meg a biztonsági frissítések tény- 
leges közzétételét. 

Don Marti 

2 dmarti(ossc.com 


A Linuxvilág 2005. májusi számának szakmai taná- 
csai között szerepel néhány helytelen és hiányos ál- 
lítás abban a válaszban, amelyet a 486-os gépeken 
Red Hat 9-et futtatni kívánó felhasználó kapott. 

Don Marti azt írta, hogy ,/A Red Hat-] utód, a Fedora 
futtatásához legalább Pentium processzor kell... 
Tulajdonképpen mindegy, hogy mit teszel fel, ezek 
a gépek egy korszerű munkakörnyezet futtatásához 
túlságosan lassúak." A RULE tervezet (www.rule- 
project.org) ezen próbál segíteni. Egy évvel ezelőtt 
már Red Hat 9-et futtattam Pentium I-es hordozható 





gépen, 32 MB memóriával. A tervezetnek köszönhe- 
tően a KOffice segítségével bemutatókat készítet- 
tem, Firefox alól pedig gond nélkül intéztem banki 
ügyeimet: 
www.rule-project.org/article.php3?id article—55 


Alig egy hónapja bemutattuk telepítőnk Fedora Core 
3-hoz készült változatát is: www.rule-project.org/ 
breve.php3?id breve— 19 


Kétségtelen, hogy egy tarkabarka KDE, GNOME 
vagy OpenOffice.org alapú telepítés bármilyen 
gépen lehet lassú, még a jóval újabbakon is. 
Ugyanez igaz a videószerkesztésre, a 3D-s játé- 
kok futtatására is, amelyekhez a mindenkori 
legjobb gép szükséges. Ha viszont a korszerű 
munkakörnyezeten az otthoni vagy kis irodai 
szolgáltatások használatát értjük — IMAP, digitá- 
lis aláírások, HTML4/CSS-támogatás, CUPS, 
azonnali üzenetküldés, Bayes-döntésekre alapuló 
levélszemétszűrés, csicsa nélkül —, akkor teljesen 
szükségtelen a pénzszórás. Az olyan tervezetek, 
mint a RULE, illetve a például a mini-KDE létre- 
hozására irányuló munkák sokkal gazdaságosabb 
lehetőségeket biztosítanak. Nem igaz tehát, hogy 
a korszerű, a fősodorba tartozó terjesztéseket 
nem lehet régebbi gépeken futtatni, csak egy 
odafigyelésre, a probléma gondosabb kezelésére 
van szükség. 

Marco Fioretti 

2 mfiorettiomoclink.it 


Linux Journal 2005. június, 134. szám 





ITL LÉT 


A legnagyobb baj az, hogy újra kell írni a költség- 
vetést, és ki kell találni, hogy mit kezdjünk azzal 

a pénzzel, ami eddig a Microsoftnak ment. 

Boyce Williams, beszélgetés Doc Searls IT Garage- 
ében (garage. docsearls.com/node/550) 


Ne úgy gondolkozz, mint egy költségközpont, 

úgyis csak megvonják a keretedet. Úgy gondolkozz, 
mint egy vállalkozó. 

Névtelen, szintén Doc Searls IT Garage-ének egyik 
beszélgetéséből (garage. docsearls.com/node/550) 


A környezetükben műszaki zseninek tekintett 
személyek és a professzionális szolgáltatásokat 
igénylő amatőrök között egyre kisebb a távolság. 
Rael Dornfest 


Buheráld a gépedet! Szerintem jó dolog. 
Peggy Rogers, ,Ms. Computer", The Miami Herald 





Úgy vélem, minden programozónak ki kell vívnia az 
elismerést, függetlenül attól, hogy melyik cég adja 
a fizetését. Nézzük csak meg a szórakoztatóipart. 
Az, hogy ki hol jelenik meg a stáblistában, fontos, 
nagyon fontos kérdés. Közvetlenül befolyásolja 

a munkához való viszonyt, és kiváló képet ad arról, 
hogy ki mekkora részt vállalt a munkából. Szerintem 
ez az egyik legszebb dolog a nyílt forrás világában. 
Danese Cooper, danesecooper.blogs.com/divablog/ 
2005/0S/about attributi.htmI 


A Linux rendszermag API-ja ismét olyan rejtélyes 
módon változott, hogy a rendszermagfán kívüli 
illesztőprogramok fejlesztőit lassan a bolondok 
házába lehet zárni. Ez van, amíg az illesztőprog- 
ramjuk be nem kerül a rendszermagfába. 

Greg Kroah-Hartman, ww.kroah.com/log/2005/02/15 


Linux Journal 2005. június, 134. szám 
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DRIM pro és kontra 


A mostanában oly sokat emlegetett DRM a digitális jogkezelő rendszerek 
(Digital Rights Management) összefoglaló megnevezése. A fejlesztés 
eredeti célja a jogvédett tartalmak illegális terjesztésének és másolásának 


megakadályozása volt... 
ára azonban kiderült, hogy a DRM sajnos más 
területeken is hatékony eszköz. Segítségével 


[ót] a nagyvállalatok megszabhatják, hogy az álta- 


lunk amúgy hivatalosan megvásárolt terméket hol, hogyan 
és hányszor használhatjuk fel. 

A DRM rendszerek fejlesztése eredetileg azért indult el, hogy 
a korábbinál egyszerűbb és biztonságosabb módon lehessen 
megakadályozni a kalózmásolatok készítését, illetve hogy 

a felhasználóknak ne kelljen , megmerülni" a végfelhasználói 
szerződések megértéséhez szükséges jogi ismeretekben. 

Bár ez a cél önmagában kifejezetten jó, a DRM mostanra 
meglehetősen sok vihart kavart, mert sokan a , Digitális 
Nagy Testvért" látják benne. Az ügyben pillanatnyilag 

a legmeglepőbb talán az, hogy szinte minden résztvevőnek 
más a véleménye, de abban a legtöbben mégis egyetérte- 
nek, hogy jelen formájában a digitális jogkezelő rendszerek 
tervezete nem jó. Még olyanok is akadnak, akik szerint 

a ,kalózkodást" egyáltalán nem kellene megtiltani vagy 
szankcionálni, a digitális termékeket pedig semmilyen 
módon nem kellene védeni. 


A digitális jogkezelő rendszerek hátrányai 

A DRM csak abban az esetben lenne működőképes, ha 

a jelenlegi tervezettel szemben egységes rendszer lenne. 

A jelenlegi elképzelések azonban olyan hibákat tartalmaz- 
nak, amelyek hátrányos helyzetbe hozhatják mind a digitá- 
lis termékek alkotóit mind azok felhasználóit. 

Talán meglepő ez a kijelentés, de egyes kutatások szerint 

a vásárló általában hajlandó kifizetni azt az összeget, amit 
a termék előállítója azért kér. A probléma az, hogy a ,pénz- 
tártól való távozás után" a vásárló rádöbbenhet: nem olyan 
árut kapott, amit korlátozások nélkül felhasználhat. 
Lássuk, mi minden érheti a — hangsúlyozzuk - jóhiszemű 
vásárlót! 


Kompatibilitási problémák... 

Mivel a különböző cégek pillanatnyilag mind más módon 
próbálják megvédeni saját termékeiket, csak a saját eszközük- 
kel engedhetik megnyitnillejátszani saját, egyedi adatformá- 
tumukat. Az ehhez szükséges eszközt azonban, ami bizonyos 
esetekben csak szoftver, általában szintén pénzért kínálják. 
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Ha tehát a gyanútlan felhasználó megvásárol egy filmet tar- 
talmazó DVD-t, vagy egy elektronikus könyvet, nem biztos, 
hogy használni is tudja majd azt, mert megeshet, hogy 

a lejátszójába nem építették bele a kérdéses adatformátum 
dekódolásához szükséges modult. Ilyenkor — ha nem akar 
összeütközésbe kerülni a törvénnyel — nem tehet mást, 

új lejátszót kell vásárolnia. 

Ez nyilvánvalóan a felhasználó szabadságának korlátozása, 
hiszen vannak olyan termékek, amiket kizárólag egy bizo- 
nyos formátumban lehet megvásárolni, tehát ha a felhasz- 
náló meg szeretné venni, kényszerítve van a digitális ter- 
méket lejátszó eszköz megvásárlására. Ez a DRM legtöbb- 
ször említett hátulütője. 

Hasonló a helyzet a digitális könyvekkel. Ha valaki megvá- 
sárol egy hagyományos könyvet, akkor joga van azt elol- 
vasni bárhol és bármikor. Ezzel szemben a DRM védelme 
alatt álló digitális könyv csak egy bizonyos programmal ol- 
vasható, ami egyes platformokon esetleg nem hozzáférhető. 
Ha tehát a vásárló elmegy egy idegen helyre, ott nem 
biztos, hogy tudja olvasni a szöveget. 

És ez még csak az első probléma. 

Ha valaki megvesz egy papír alapú könyvet, miután elolvas- 
ta, továbbadhatja vagy el is ajándékozhatja azt. Ugyanennek 
a műnek a digitális változata viszont ezek ellen a galádságok 
ellen is hatékonyan védve van, hiszen a következő tulajdo- 
nos minden valószínűség szerint képtelen lesz elolvasni. 

Ez egyrészt meglehetősen egyoldalúan befolyásolja a felhasz- 
nálót abból a szempontból, hogy milyen formátumú könyvet 
vegyen, másrészt pedig úgy tűnik, a digitális forradalom be- 
köszöntével nyugdíjba vonulhat az összes antikvárius... 

A DVD-k esetében a régiókód is a digitális jogkezelő rend- 
szer része. Működésének lényege, hogy a lemezről a leját- 
szó egyértelműen meg tudja állapítani, milyen országból 
származik. Így például a Magyarországon megvásárolt DVD 
itthon tökéletesen működik, de mondjuk New York-ban 
már nem lehet lejátszani. 

A dolog pikantériája, hogy jelenleg egyszerűen nincs olyan 
szerzői jogi törvény, amely a szerzőnek illetve forgalmazó- 
nak lehetővé tenné, hogy a vásárlót ilyen módon és mérték- 
ben korlátozza. A digitális jogkezelő rendszerek működése 
tehát pillanatnyilag egyszerűen jogsértő. 
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Biztonsági másolatok... 

Az is előfordulhat, hogy egy legális termékről (például egy 
DVD-ről) a vásárló biztonsági másolatot szeretne készíteni. 
Ilyenkor az egyik forgatókönyv szerint már maga a DVD-író 
program nem engedi lemásolni a lemezt, hanem kiírja, 
hogy annak tartalmát szerzői jog védi, illegális másolat 
készítése pedig tilos... 

A másik lehetőség, hogy a másolás ugyan sikerül, de a le- 
játszóban már nem működik a másolat. 

Hasonló esettel kerülhetünk szembe, ha egy mobiltelefonra 
töltünk le alkalmazásokat. Ha a felhasználó letöltött egy prog- 
ramot, általában lementi azt a számítógépére is, gondolván ar- 
ra az esetre, ha netán valami baleset érné a , kézi készüléket. 
Emberünk, mivel egyszer már kifizette az alkalmazás árát, 
joggal gondolhatja úgy, hogy minden további nélkül vissza- 
töltheti azt a telefonjára. Ezzel szemben ha az alkalmazást 
DRM védi, a számítógépről való visszatöltés után hibaüze- 
netet fog kiírni, mondván a program egy illegális másolatát 
próbáltuk meg futtatni. Ezután a felhasználónak nincs más 
választása, mint hogy újból kifizesse a termék árát, hogy az 
ismét működőképes legyen. 

A képzettebb - és főleg öntudatosabb -— fogyasztók persze 
ilyenkor a megfelelő segédeszközökhöz nyúlnak majd. 
Nem, nem a házi jogtanácsosukról van szó... 

Akárcsak eddig a szoftverkalózok tették, megpróbálják 
majd kikerülni a másolásvédelmi rendszert. Léteznek majd 
olyan programok, amiket csak le kell futtatni, és a digitális 
jogvédelem már el is tűnt a termékből. Ez természetesen 
ugyanúgy illegális, mint a szoftverek másolása. A különb- 
ség csak annyi, hogy most a jogos tulajdonos lopta el az 
anyagot. De pontosan kitől is?... 

Ami a biztonságtechnika alapelveit illeti, a DRM megalkotói 
úgy tánik elkövettek egy szarvashibát: átadják a vásárlónak 

a kódolt terméket, a dekódoló eszközt, és a kulcsot is. Ez a fel- 
állás tulajdonképpen a teljes rendszer értelmét kérdőjelezi 
meg, hiszen ezek után hatékony védelemről szó sem lehet. 
Ha egy felhasználót eleve tisztességes szándék vezet, attól 
fölösleges a kérdéses anyagot megvédeni. Aki pedig jogta- 
lanul akar egy tartalomhoz hozzáférni, az némi ügyeskedés 
árán a DRM ellenére is megteheti, hiszen várhatóan pilla- 
natokon belül meg fognak születni a DRM kikerülését lehe- 
tővé tevő programok. 

Minderre a digitális jogkezelő rendszereket alkalmazó 
cégek azt mondják, hogy a DRM nem a szervezett kalóz- 
csoportok, nem az ügyes egyetemisták sőt még csak nem 

is azok ellen készült, akik képesek kreatív módon használni 
a Google-t vagy a Kazaa-t, hanem az , átlagos felhasználók" 
ellen. A DRM tehát az ő olvasatukban nem egyéb, mint 

a villanypásztor digitális megfelelője. 

A gondolatmenetben mindössze annyi a hiba, hogy a gyár- 
tók sokak szerint messze alulbecsülik az , átlagos felhaszná- 
ló" képességeit. Az említett programoknak ugyanis csak 

a megírása igényel különleges felkészültséget, a használata 
nem. Tény, hogy ismerni kell hozzájuk az egér és a billentyű- 
zet kezelését, de aki erre sem képes, attól nem a DRM fogja 
megvédeni a digitális tartalmakat, hanem a saját butasága. 


Valami Amerika — avagy az EUCD 
Az EUCD az Amerikai Egyesült Államokban érvényes 
DMCA (Digital Millennium Copyright Act) európai 
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változata. Amerikában a DMCA elsősorban azzal 

vívta ki a társadalom ellenszenvét, hogy a törvény 
megtiltotta a kutatók számára a másolásvédelmi tech- 
nológiák tanulmányozását, valamint azt, hogy nyilvá- 
nos ságra hozzanak olyan információkat, amelyek 
ezeknek a technológiáknak a hibáival, biztonsági 
réseivel kapcsolatosak. 

Az EUCD arra kötelezi az Európai lnió országait, 

hogy olyan törvényeket léptessenek életbe, melyek 
megfelelő jogi védelmet biztosítanak a különböző titko- 
sításoknak, másolásvédelmeknek és egyéb, a szerzői 
jogokat védő műszaki megoldásoknak. Az EUCD azt 

is kimondja, hogy az Európai Unió országaiban minden 
lehetséges eszközzel meg kell akadályozni az olyan 
elektronikai eszközök forgalomba kerülését, melyeket 
készítőik nyilvánvalóan egyes digitális védelmi rendsze- 
rek kiiktatására terveztek. 

2004. július 29-én létrejött egy digitális jogkezelő rendsze- 
rekkel foglalkozó munkacsoport (DRM munkacsoport), 
amely a digitális jogkezelő rendszerek hatását és szüksé- 
gességét vizsgálja jogi és technikai szempontból. A munka- 
csoport 2005. július 1-ére készíti el összefoglaló jelentését 
a kormány számára. 


Lehetséges megoldások a DRM és az EUCD , kijavítására" 
Oktatási célokra valamilyen mértékben mindenképpen 
hozzáférhetővé kellene tenni azokat a műveket, amelyek 

a tanuláshoz szükségesek, de egyébként a szerzői jogvédel- 
met élveznek. Ennek egyrészt történelmi jelentősége van, 
hiszen a felnövekvő nemzedék nem lehet a jelen jogi csatá- 
rozásainak áldozata, másrészt hazánkban z az iskolák anya- 
gi helyzete is indokolja. 

A kompatibilitási problémák elkerülése érdekében a fej- 
lesztők számára elérhetővé kellene tenni a különböző 
formátumok és digitális jogkezelő rendszerek működésé- 
nek leírását. Ez a DRM rendszerek biztonsága érdekében 
is kívánatos volna, hiszen csak a technológia ismerete 

ad lehetőséget a fejlesztőknek arra, hogy a benne talált 
hibákat kijavítsák. 

A vonatkozó törvényekben engedélyezni kell saját célra 

a biztonsági másolatok készítését, műszaki oldalról pedig 
lehetővé kell tenni azok felhasználását. 

Az utóbbi időben egyre több az olyan dokumentum, amely 
eleve csak digitális formában jelenik meg. Ha mindent ilyen 
anyagot DRM védene, a digitális művek terjedése nagy 
mértékben lelassulna, ez pedig lassan az írók és fejlesztők 
hátrányára is válna. Azt tulajdonképpen ma sem vitatja 
senki, hogy a szerzőknek is az a jó, ha művük ismert és 
gyorsan terjed. 

Összességében elmondható, hogy a DRM jelenlegi terveze- 
tével mindenki elégedetlen, legyen akár szerző, kereskedő, 
vagy egyszerű vásárló. A legtöbben arra várnak, hogy meg- 
jelenjen egy egységes és fejlett jogkezelési rendszert, és erre 
talán van is némi esély. A jelenlegi DRM azonban semmi- 
képpen sem ilyen. 


Guba Norbert (nguba-oxmonornet.hu) 

Tanuló, körülbelül 3 éve használ Linuxot. Szabadidejét 
leginkább programozással tölti, hobbija az operációs 
rendszerek gyűjtése. 








Gazdálkodj okosan! 


Mindig értetlenül állok olyan üzleti célú szoftverek előtt, melyek csak egyetlen 
operációs rendszer alatt működnek. A fejlesztőcégek bele sem gondolnak abba, 
hogy létezhetnek más megoldásokat használó potenciális ügyfelek is? 


ontosan úgy, ahogyan egy operációs rendszernek 
E; az összes lehetséges hardver felett el kellene futnia, 

úgy kellene a könyvelő, útnyilvántartó, ügyfélkap- 
csolati szoftvereknek is működnie lehetőleg az összes ope- 
rációs rendszer felett. Lehetőség éppen lenne rá... 
Úgy látszik, ahogy egyfelől az innovációnak nincsenek 
korlátai, úgy bizonyos esetben a korlátoltságnak sem. 
Nézzünk meg tehát egy gyöngyszemet a sötét tenger fene- 
kén, melynek neve SOL-Ledger és a két gyöngyhalász, aki 
most felszínre hozza nekünk ezt a gyöngyöt: Kabai József 
és Sásdi András. 


Először is azt szeretném, ha egy pár szóban összefoglalnád 

a magyar ügyviteli szoftver piac helyzetét jelenleg, mik azok 
amik jók, mik azok amik hiányosságok? 

KJJ.: Az ügyviteli szoftverek hagyományosan Windows ope- 
rációs rendszeren futnak. Ez az ügyviteli szoftverek túlnyo- 
mó többségét, vagyis körülbelül 90-9595-át jelenti. Az a ta- 
pasztalatunk, hogy a Linux világában nagyon nagy hiány 
van az ügyviteli szoftverekből, és ezért az SgI-Ledger egy 
nagyon jó jelölt azoknak, akik Linuxot használnak. 


Vannak-e olyan más szabad ügyviteli szoftverek, amik 
hasonlóak az SOL-Ledgerhez? 

K.J.: Természetesen vannak, hiszen az egész világon fejlesz- 
tenek szabad szoftvereket ügyviteli célokra. Mi körülbelül 
két évvel ezelőtt kezdtünk ezzel komolyabban foglalkozni, 
és úgy ítéltük meg, az Sg1-Ledgernek van a legbíztatóbb 
fejlesztési modellje és a legjobb fejlődési üteme. Most már 
elmondhatjuk, hogy megérzésünk nem okozott csalódást, 
hiszen azóta is nagyon dinamikusan fejlődik, és elmondhat- 
juk, hogy a kis- illetve középvállalatok számára a legjobb, 
legtöbb funkcióval rendelkező szabad szoftver. 


Nem sok cég van idehaza, akik a szabad szoftverekhez nyúj- 
tanak támogatást, tehát tulajdonképpen honnan jött az ötlet, 
hogy ti egy szabad szoftvert karoltok fel, nem pedig egy 
külföldi kereskedelmi szoftverrel kezdtek foglalkozni? 

K.J.: Természetesen nem az volt az első szándékunk vagy 
ötletünk, hogy mi ezt termékké alakítsuk át. Egy több milli- 
árdos forgalommal rendelkező kereskedelmi cég keresett 
meg minket azzal, hogy szeretne egy olyan rendszert, 
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amely az ő igényei szerint működik, és sokkal jobb megol- 
dásnak tűnt, hogy keresünk egy szabad szoftvert, amit mi 
átalakíthatunk, ahelyett, hogy egy zárt forráskódú szoftvert 
fejlesztő céggel kezdünk egyezkedni, hogy , szabja testre" 
saját termékét a cég igényei szerint. A mi termékünk végül 
ebből a fejlesztésből alakult ki. 


Tehát akkor tulajdonképpen ti is hozzáraktatok valamit 

az SOL-Ledgerhez. Tudsz mondani erre konkrét példát, 
vagyis valamit amit ti fejlesztettetek ki? 

KJ.: Az Sgl-Ledger egy globális könyvelési rendszer, olyan 
funkciókkal rendelkezik, ami a legtöbb országban működik. 
Magyarországon vannak olyan speciális tulajdonságai 

a könyvelési, ügyviteli szabályoknak, amelyek ebben a prog- 
ramban természetesen nem voltak benne. Magyarországon 
van az egyik legszigorúbb számlázási rendelet, a magyar 
könyvelők más szempontból tekintenek a könyvelésre, más 
módszer alapján könyvelnek le egy számlát, mint az angol- 
szász országokban. Lévén az Sgl-Ledger egy kanadai prog- 
ram, sok módosítást kellett rajta elvégezni ahhoz, hogy 

a magyar viszonyok között is kényelmesen működjön. 
Ezeket a módosításokat természetesen vissza lehetne rakni 
az eredeti programba, de nem kerülnek bele, hiszen itt ha- 
zánkra nézve teljesen specifikus dolgokról van szó. 


Az eredeti programot ugyebár nem ti fejlesztitek, ti csak 
hozzáraktok bizonyos részeket. Nem okoz-e nagy problémát, 
ha a szoftver kanadai fejlesztők átalakítanak valamit? 
Könnyen hozzá tudjátok-e igazítani az új változathoz is saját 
fejlesztéseiteket, mondjuk egy modul formájában, vagy azért 
ennél egy kicsit problémásabb a helyzet? 

KJ.: Igen, ez valóban probléma, hiszen figyelni kell arra, 
hogy az eredeti szerző mit fejleszt bele, illetve a mi változ- 
tatásainkat is figyelni kell, hogy jól működjön az új verziók- 
kal. Ezt a problémát úgy oldottuk meg, hogy le lehet tölteni 
az eredeti verziót az oldalunkról valamint az eredeti verzi- 
ónak a magyar fordítását, illetve a magyar sablonokat, tehát 
ha valakinek erre van szüksége, akkor nyugodtan ingyene- 
sen használhatja, ha viszont már számlázni akar vele, vagy 
szeretne egy kicsit a magyar viszonyokhoz közelibb felüle- 
teteket kapni a munkája során, akkor minket keres meg, és 
a mi verziónkat adjuk oda, amibe természetesen egy kicsit 
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később kerülnek bele azok a magyar felhasználók számára 
is hasznos tulajdonságok, amelyeket a kanadai szerző folya- 
matosan fejleszt a programba. 


Mivel bárki szabadon letöltheti, például a Ti oldalatokról 

is a forráskódot, ezért elvileg holnaptól bárki elkezdheti 
terjeszteni. Nem féltek ettől, vagy nem jelent ez valamilyen 
kockázatot számotokra? 

S.A.: Természetesen sok energiát és munkát fektettünk 

a szoftver fejlesztésébe, de mi tudjuk, hogy a szolgáltatás 
árát kell úgy megállapítani, hogy az versenyképes legyen. 
A cél tehát az, hogy a hozzáadott érték, vagyis az a többlet, 
amit mi az SOL-Ledgerhez adunk, a legjobb legyen a pia- 
con, és ezért potenciális ügyfeleink bennünket válasszanak. 
Természetesen itt is versenyhelyzet van, mint mindig és 
mindenütt, de ezt a versenyt mi álljuk. 


Gondolom az ügyfeleitek egy része egy kicsit félt kezdetben 

a szabad szoftverektől. Nem tudták mondjuk, hogy elég meg- 
bízhatóak-e, illetve ha van benne valami hiba, akkor kié a fele- 
lősség. Ennek ugye jelen esetben akár komoly anyagi vonzata 
is lehet. Hogyan sikerült az ügyfeleiteket mégis megnyugtatni? 
K.J.: A szolgáltatásunk nagyon fontos része a havi támoga- 
tás, tehát bármilyen probléma esetén minket fel lehet keres- 
ni e-mailben, szükség esetén távoli eléréssel megnézzük 

a rendszert, kijavítjuk a hibákat, vagyis gyorsan tudunk 
reagálni a problémákra. Ami a megnyugtatást illeti, jellem- 
zően olyan emberek, olyan ügyfelek, cégek keresnek meg 
bennünket, akiket eleve vonz a szabad szoftverekkel kap- 
csolatos filozófia. Ha úgy döntenek, akkor nem a mi szol- 
gáltatásunkat veszik igénybe, tehát megkereshetnek bárki 
mást, a kényszerfüggőség számukra nem létezik. Ettől füg- 
getlenül legtöbben minket választanak, hiszen mi értünk 
hozzá a legjobban, ami a testreszabást illeti mi tudunk 

a legjobb árakkal szolgálni, illetve mi tudunk a leggyorsab- 
ban reagálni a problémákra. 


Akkor tehát úgy tűnik, hogy lassan kezd kialakulni a biza- 
lom a szabad szoftverek iránt. Ti is így látjátok? 

S.A.: Tény, hogy amit mi a szabad, vagy nyílt forráskódú 
rendszerek népszerűsítése terén teszünk, az egyfajta misszi- 
ós tevékenység is. Azt próbáljuk minden potenciális ügyfe- 
lünkkel megértetni, hogy éppen akkor van biztonságban, 
ha a nyílt forráskódú, szabad szoftver mellett teszi le a ga- 
rast, és éppen akkor futhat be egy veszélyes zsákutcába, ha 
valamilyen zárt forráskódú kereskedelmi szoftvert vásárol 
meg. Ilyenkor ugyanis a szolgáltató monopol helyzetben 
van és — durván fogalmazva — ,elszemtelenedhet". 


Mik voltak azok az igények, amelyeket az ügyfeleitek a régi 
ügyviteli szoftverükkel nem tudtak megvalósítani, ugyanak- 
kor az SOL-Ledger az erre már alkalmas volt? 

KJ.: A legfontosabb, hogy Linux alatt stabilan fut, valamint, 
hogy szabad szoftver. Vonzó az is, hogy másképp van fel- 
építve ez a program, tehát egy könyvelési tudással nem 
rendelkező ügyvezető is biztonsággal tudja használni. 

A program a bizonylatok rögzítésekor a háttérben automa- 
tikus lekönyveli a tételeket, ezért a kezelőnek nem kell tud- 
nia, hogy milyen főkönyvi számokat kell beírnia az űrlapra, 
hogy ez rögzítésre kerüljön. A program ezt , magától" tudja. 
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Az SOL-Ledger mellett szól az is, hogy nagyon jól lehet 
használni intranet hálózatokon, illetve interneten keresztül 
is. Elég föltelepíteni egy szerverre, és a webes felületének kö- 
szönhetően bárhonnan elérhető a program. Az utazó eladók, 
otthonról netező ügyvezetők is meg tudják nézni, hogy mi- 
ből mennyi van raktáron. Persze rögtön hozzá kell tenni, 
hogy megfelelő biztonsági eszközöket azért használni kell. 
Végül többen a nyitottsága miatt szeretik, azaz könnyen 
összeköthető más rendszerekkel, mint például Webáruház. 


S.A.: Nem is az a lényeg, hogy Linuxon is fut, hanem, hogy 
alapvetően Linuxon fejlesztették, és így a rendszert kiszol- 
gáló programok is szabadok és ingyenesek. Még az adat- 
báziskezelője (PostgreSOL) is ingyenes, sőt ismereteim 
szerinti ez a legfejlettebb adatbázis motor, ami Linux alatt 
elérhető. Nagyon sokan pontosan azért váltanak erre 

a szoftverre, mert egy fejlettebb felületet és egy fejlettebb 
rendszert szeretnének. A rendszer a cég vezetését átlátható 
információkkal látja el, ami nagyon fontos lehet a vállalat 
vezetőinek az üzleti döntések meghozatala során. 


Nincs a webes felületnek valami hátránya? Mondjuk 
valamelyik böngésző esetleg nem tud kezelni bizonyos 
adatmennyiséget? A nyomtatásnál is a böngészőre vagytok 
utalva, vagy nem? 

K.J.: Nos igen, a programnak az a legnagyobb hátránya, 
hogy az adatokat webes felületen kell rögzíteni, egy köny- 
velő pedig ahhoz van szokva, hogy könnyen és gyorsan 
tudjon felvinni dokumentumokat, számlákat. Már dolgo- 
zunk ennek a kiváltásán. A nyomtatás természetesen 
nem csak úgy működik, hogy a böngészőben megjelenít- 
jük és onnan nyomtatjuk ki az anyagot. A program képes 
PostScript és PDF formátumot is előállítani, amelyet vagy 
megjelenítünk a képernyőn (és onnan nyomtatjuk ki), 
vagy közvetlenül a nyomtatóra irányítjuk. 


Akkor gyakorlatilag milyen százalékban van a windowsos 
és linuxos kiszolgálóra telepített programok aránya? 
S.A.: 9999 Linux, 17 Windows. 


K.J.: Ehhez annyit azért hozzátennék, hogy természetesen 
Windowsra is lehet telepíteni. Azok a segédprogramok, 
amik Linuxra ingyenesek, ugyanúgy Windowson is meg- 
vannak, és ugyanúgy ingyenesek. A Windowsnál egyedül 
az operációs rendszert kell megvásárolni. A windowsos 
változatnál annyi a probléma, hogy egyelőre nincs alaposan 
letesztelve, hiszen az adatbázismotor Windowsra írt natív 
verziója (a 8.0-ás) gyakorlatilag a közelmúltban jött a ki. 
Úgy érezzük ezt még alaposan le kell tesztelni ahhoz, hogy 
biztonsággal tudjuk támogatni. Alapos tesztelés után vi- 
szont ugyanolyan egyenértékű lesz, mint Linuxon. Persze 
lehet keverni is a megoldásokat. Például meg lehet azt is 
oldani, hogy minden a Windowson fut, kivéve az adatbá- 
zismotort, amely Linux kiszolgálón van. Ha a szerveren 
kész a telepítés, attól kezdve a rendszer egy egyszerű bön- 
gészővel ellátott bármilyen operációs rendszert futtató 
munkaállomásról használható, legyen az Linux, Windows 
vagy egy Macintosh. 


Az interjút Horváth Ernő készítette 








Program által meghatározott processzorok 


A rendszerlogika menet közben megvalósított újraépítésével ez a módszer 
képessé tehet egyetlen FPGA-t tíz vagy akár több száz közönséges processzor 


feladatainak ellátására. 


z alkalmazás által meghatározott processzorok 
A az átszerkeszthető számítási elv (reconfigurable 

computing, RC) elvén alapulnak. Az RC egy olyan 
számítási eljárás, amely elmossa a hardver és szoftver köz- 
ti határvonalat és megteremti az alapjait annak, hogy 
újabb nagy lépést tegyünk a számítási hatékonyság növe- 
lése terén, csökkentett teljesítmény- és tárterület-igény 
mellett. Az RC gyakorlati megvalósítása az átszerkeszthető 
(reconfigurable) hardvereszközök alkalmazásával történik. 
Egy RC-rendszerben lévő processzorok olyan hardver- 
eszközök, amelyek a rajtuk futtatott programra lettek 
optimalizálva. 
Cikkemben elmagyarázom az RC eljárás elvét, megvizs- 
gálok néhány SRC-rendszert, amelyek az RC gyakorlati 
megvalósítását jelentik, és megmutatom, hogy milyen 
teljesítménybeli előnyökkel bír az RC a hagyományos 
mikroprocesszorokhoz képest. Bemutatom emellett az 
RC programozási modelljét és az RC-ben rejlő lehetősé- 
geket az Open Hardware támogatására. 


Mit jelent az átszerkeszthető számítási elv és miért 
fontos ez a számunkra? 

Az RC egy a hardveren alapuló számítási módszer, amely 
minden egyes futtatandó alkalmazás számára dinamikusan 
hozható létre. Az RC olyan hardverelemekből épül fel, ame- 
lyek dinamikusan megadható logikájú áramköri lapkákat 
tartalmaznak, vagyis az alkalmazott számítási módszer nem 
a gyártáskor kerül rögzítésre. Az RC már sok éve létezik, 

és számos hardverösszetevőben került már megvalósításra. 
Ilyenek az FPGA-k (Field Programmable Gate Array, általá- 
nos célú programozható áramkör), az FPOA-k (Field 
Programmable Object Array, az FPGA-hoz hasonló jellegű, 
de számos fontos tulajdonságában eltérő programozható 
áramkör - a ford.) és az összetett programozható logikájú 
eszközök (complex programmable logic devices, CPLD). 

Az alkalmazásfejlesztők számára fontos tényező, hogy 

a modern újraszerkeszthető áramköri lapkák olyan óra- 
jellel és teljesítménnyel rendelkeznek, amelyek lehetővé 
teszik, hogy RC-hardverekben nagyteljesítményű számítá- 
sokra is alkalmazzák azokat. 

Az RC megvalósítására használt legelterjedtebb lapkatípus 
az FPGA. Az FPGA SRAM memóriacellákból felépülő lapka, 
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amelyben ezek a memóriacellák tárolják a lapka beállításait. 
Az FPGA-k logikai kapukat, flip-flopokat, RAM-ot, arit- 
metikai magot, órajel-generátort és az ezek összekötésére 
szolgáló beállítható huzalozást tartalmaznak. Az FPGA-k 
tetszőleges logikai funkció megvalósítására beállíthatók, 
így olyan egyedi processzorok hozhatók létre, melyek egy 
adott alkalmazásra optimalizálhatók. 

Egy FPGA-készlet így alkothat akár MIPS, SPARC PowerPC 
vagy Xeon processzort, esetleg egy teljesen egyedi felépítés- 
sel rendelkezőt is. Valójában az sem szükséges, hogy 
utasításfeldolgozó egységről legyen szó, közvetlen futtató 
logika (DEL, direct execution logic) is lehet, amely csak szá- 
mítási logikát tartalmaz, és nincs szüksége az algoritmust 
meghatározó utasításokra. 

A közvetlen futtató logikát tartalmazó (DEL) processzorok 
igen nagy teljesítmények elérését teszik lehetővé. Ezek 

a processzorok pontosan az adott algoritmus végrehajtásá- 
hoz szükséges erőforrásokkal hozhatók létre. A hagyomá- 
nyos utasításfeldolgozó egységek rögzített erőforrásokkal 
rendelkeznek, összeadókkal, szorzókkal, regiszterekkel és 
átmeneti tárakkal, és jelentős lapkafelület és teljesítmény 
szükséges az olyan többletmunka végrehajtásához, mint az 
utasítások visszafejtése, a végrehajtási sorrend megállapítá- 
sa és az átmeneti tár kezelése. 

A DEL-processzorok olyan átrendezhető számítógépek, 
amelyekben minden alkalmazáshoz más-más felépítés 
tartozik szemben a rögzített felépítésű processzorokkal, 
amelyeknél mindent ugyanazzal az egységgel kell meg- 
oldani. A DEL-processzorok a leghatékonyabb áramköri 
felépítést szolgáltatják egy adott alkalmazáshoz az algo- 
ritmusban található párhuzamosságok kezelésének és 

a funkcionális egységek pontosságának tekintetében. 

Az átépíthetőségből adódóan minden program számára 
egyedi DEL-processzor hozható létre a másodperc tört- 
része alatt. 

De miért fontos számunkra, hogy a DEL-processzorok 
dinamikusan hozatók létre egy alkalmazás számra és hogy 
hatékonyabban használják ki a rendelkezésükre álló áram- 
köri lapkákat, mint a hagyományos mikroprocesszor? 

A válasz egyszerű: hatékonyabb teljesítmény- és energia- 
felhasználás. Egy DEL RC processzor úgy építhető fel, 
hogy tartalmaz minden párhuzamosságot, ami az adott 
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Intel Pentium 4 Processzor Közvetlen végrehajtási logika 


1. ábra A közvetlen futtatású logika (DEL) minden logikai kaput a valódi 
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3. ábra A MAP szerkezeti felépítése 


algoritmusban előfordul, a mikroprocesszorban lévő 
felesleges többletmunka nélkül. A cikk további részében 
a téma részletesebb tárgyalásának érdekében az RC pro- 
cesszorokat FPGA elemekkel megvalósított egységeknek 
feltételezzük. 


Hogyan érhető el az a bizonyos nagy teljesítmény? 

Az RC processzorok teljesítménye a logika párhuza- 
mos futtatási képességéből adódik. Az RC processzorok 
teljes mértékben párhuzamos működésűek. Valójában 
egy adott algoritmusnak megfelelő logika létrehozása 
nem áll másból, mint a párhuzamos futások összehan- 
golásából, vagyis hogy a részeredmények a megfelelő 
pillanatban jöjjenek létre, kerüljenek megosztásra illetve 
visszatartásra. 

A DEL processzor az adatutak és vezérlőjelek által össze- 
kapcsolt funkcionális egységek hálózata. A hálózatban lé- 
vő minden számítási egység minden egyes órajelre aktívvá 
válik. Az 1. ábra egy logikai részletet mutat egy kifejezés 
kiszámítására és a lapka kihasználtságára egy olyan 
Neumann-féle utasítás-processzorban, mint amilyen 

az Intel Pentium 4 mikroprocesszor is. 
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Az egy SRC MAP-nak megfelelő 2,8 GHZ-es processzorok száma 
egy kiválasztott algoritmus életében 
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2. ábra Számos 2.8 GHz-es processzor szükséges a MAP közvetlenül 
futtató processzor teljesítményének az eléréséhez 
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4. ábra A fürtözött SRC-6 rendszer felépítése 


Habár egy mikroprocesszor 3GHz körüli órajelen képes 
működni szemben az FPGA lapkák 100-300 MHz-es frek- 
venciájával, a párhuzamosságnak és a belső sávszélesség- 
nek köszönhetően egy DEL-processzor az összteljesítményt 
tekintve nagyságrendekkel múlhatja felül a mikropro- 
cesszort. A 2. ábrán néhány összehasonlító teljesítményteszt 
látható, amelyben az SRC DEL-processzora a MAP és egy 
jellegzetes Neumann-féle utasításvégrehajtó processzor, 

az Intel Xeon 2,8 GHz mikroprocesszor méri össze erejét. 

A párhuzamos futás, a pontosan a szükséges számú funkci- 
onális egység alkalmazása, a nagy belső sávszélesség, az 
utasítás feldolgozásából, betöltéséből és tárolásából adódó 
többletmunka kiküszöbölése együttesen vezetnek a MAP 
és Intel processzorok közti 30-szoros órajelkülönbséghez. 


Képes a DEL processzor a Linux futtatására? 

Elvileg a DEL alapú processzorok képesek lennének 

a Linux futtatására, de szükség van-e erre egyáltalán? 

A Linux rendszermagjának kódszegmensei minden 
bizonnyal nagyobb teljesítménnyel futnának egy DEL 
processzoron, és a Linux rendszercsomag programjai is 
éreznék ennek az előnyét. Mégis, egy operációs rend- 
szernek, és különösen a rendszermagnak az a szerepe, 
hogy kezelje a hardvert, és elérhetővé tegye a programok 
számára a megfelelő teljesítményszintet. Más szóval 








az operációs rendszernek félre kell állnia az útból és hagyni, 
hogy az alkalmazások kihasználhassák a hardver nyújtotta 
szolgáltatásokat. 

A programok nem csak elmélyült számítási műveletekkel 
foglalkoznak, hanem emellett kapcsolatot tartanak a fel- 
használókkal, fájlokat olvasnak és írnak, megjelenítik az 
eredményeket és a Világhálón keresztül információt cserél- 
nek a világgal. Az alkalmazásoknak tehát egyaránt szüksé- 
gük van számítási erőforrásokra és egy operációs rendszer 
szolgáltatásaira. A nehéz számítási műveletek és a magas 
fokú párhuzamosság ki tudja használni a DEL processzorok 
előnyeit. Bár a soros kódok is futhatnak közvetlen futtató 
logikán, ezeket mégis a hagyományos processzorok tudják 
a legjobban kiszolgálni. 

A legtöbb alkalmazás számára az optimális megol- 

dást a hagyományos és DEL processzorok keveréke 
jelenti. Ez a kombináció lehetővé teszi az alkalmazások 
számára, hogy nagyságrendekkel nagyobb teljesít- 
ményt érjenek el, miközben a hagyományos Linux 
környezetben futnak és rendelkezésükre áll az operációs 
rendszer összes szolgáltatása és megszokott eszköze. 

Az alkalmazásnak azok a részei, amelyben túlsúlyban 
vannak a soros kódok, vagy amelyek az operációs 
rendszer szolgáltatásait igénylik, a rendszer hagyomá- 
nyos processzort tartalmazó részén futhat, míg azokat 

az alkalmazásokat, sőt az operációs rendszer bizonyos 
részeit, amelyek számára előnyös a DEL párhuzamos- 
sága, a szorosan a rendszerhez kapcsolt DEL processzo- 
rok szolgálják ki. 


Az SRC Computers RC-rendszere 

Az SRC létrehozott DEL-processzorokat és mikroprocesszo- 
rokat egyaránt tartalmazó rendszereket. Ezek a rendszerek 
operációs rendszerként a Linuxot futtatják, emellett biztosí- 
tanak egy Carte nevű programozói környezetet, amely 
alkalmas a mikroprocesszoros utasításokat a DEL-lel ötvö- 
ző programok írására, és egyetlen rendszeren belül támo- 
gatja a mikroprocesszorra és DEL-processzorra épülő 
hardverhátteret. 


A DEL-processzor: MAP 

A MAP az SRC nagyteljesítményű, szabadalmazott DEL- 
processzora. A MAP átszerkeszthető összetevőket tartalmaz 

a vezérlés és felhasználó által meghatározott számítások 
megvalósítására, az előzetes utasításkód-lehívásra és az adat- 
elérésre. Ez a számítási képesség igen nagy belső és külső 
sávszélességgel párosul. A MAP kétkapus alaplapra integrált 
memáóriái 11,2 GB/sec helyi átviteli sebességet biztosítanak. 

A MAP külön bemeneti és kimeneti kapukkal van felszerelve, 
amelyek 14 GB/sec adatforgalom kezelésére képesek. Ezen 
felül minden MAP rendelkezik két általános [/D (GPIO) ka- 
puval további 4.8 GB/sec sávszélességet biztosítva a közvetlen 
MAP-MAP kapcsolat vagy a forrásadatok számára. A MAP- 
processzor szerkezeti felépítését a 3. ábrán láthatjuk. 


A mikroprocesszorok kapcsolódása a SNAP segítségével 
Az ezekben az eszközökben használt DLD-k (Dense 

Logic Device, hagyományos fix logikájú eszközök) 
kétprocesszoros Intel IA-32 egységek. Ezek a külső 




















www.linuxvilag.hu 


2005. július 21 


0 Kiskapu Kft. Minden jog fenntartva 








Szaktekintély 


0 Kiskapu Kft. Minden jog fenntartva 











Gigabit 
audú al 














5. ábra A Hi-Bar kapcsolóval felépített SRC-6 elrendezése 
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6. ábra A Carte programozói környezet 
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7. ábra A Carte fordításának folyamata 


gyártótól származó áramkörök az SRC által kifejlesz- 

tett SNAP-felülethez csatlakoznak. A SNAP lehetővé 
teszi a hagyományos alaplapok csatolását és a memó- 
riamegosztást a MAP processzorokkal és a közös 
memóriacsomópontokkal, amelyek az SRC-rendszer 
további észét képezik. 

A SNAP-felületet úgy tervezték, hogy az ne a mikro- 
processzor ki/bemeneti alrendszerére, hanem közvetle- 
nül a memória-alrendszerhez csatlakozzon, ezáltal lénye- 
gesen nagyobb csatlakozási sávszélességet biztosítva. 
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A SNAP külön kimeneti és bemeneti kapukat használ, 
amelyek jelenleg 14 GB/sec átviteli sebességet tesz- 

nek lehetővé. 

A SNAP intelligens DMA-vezérlője olyan összetett utasítás- 
kód-előreolvasásra és adatelérési műveletekre képes, mint 
az adattömörítés, lépdelő (strided) adatelérés és a szó- 
rás/összegyűjtés, amelyek mindegyike a rendszerkapcsola- 
tok rendelkezésére álló átviteli sávszélességének minél jobb 
kihasználását célozza. A kapcsolódás hatásfoka több mint 
tízszer jobb egy átmeneti tárat használó mikroprocesszoré- 
nál, amely az ilyen műveletekhez általánosan használt kap- 
csolatokat alkalmazza. 

A SNAP csatlakozhat közvetlenül egyetlen MAP-hez, vagy 
az SRC Hi-Bar elosztójához több MAP, mikroprocesszor, 
vagy a közös memória eléréséhez. 


Az SRC-6 rendszer szintű felépítésének megvalósítása 
A rendszer-szintű beállítások vagy egy MAP-állomásokból 
álló fürtöt, vagy egy kapcsolóval megoldott kereszt-elren- 
dezést valósítanak meg. A 4. ábrán is látható fürt-alapú 
rendszerek a mikroprocesszort és a korábban ismertetett 
DEL-processzort közvetlen kapcsolatban használják. 
Habár ez az elrendezés a hagyományos és DEL-processzor 
szoros kapcsolatára épül, mégis ki tudja használni a szab- 
ványokra épülő fürtözési technikát a nagyon gyors rend- 
szerek megvalósításához. 

Amikor ennél nagyobb rugalmasságra van szükség, 
alkalmazhatók a Hi-Bar kapcsolókra épülő rendszerek. 

A Hi-Bar az SRC saját fejlesztésű skálázható, nagy sáv- 
szélességű és kis válaszidejű kapcsolója. Minden Hi-Bar 
támogatja a 64 bites címzést és 16 bemeneti valamint 

16 kimeneti kapuval rendelkezik a 16 csomóponthoz való 
csatlakoztatáshoz. A Hi-Bar-hoz csatlakozhatnak mikro- 
processzorok, MAP-ek és közös memóriák bármilyen, 

a 4. ábrán is látható elrendezésben. Minden be- és ki- 
mentei kapu 14 GB/sec átviteli sebességgel rendelkezik, 
amely így egy kettéosztott 22,4 GB/sec sávszélességgé 
adódik össze a 16 kapun. A kapu-kapu késleltetés 180 ns 
a kapunkét megvalósított egyszeres hibajavítással és két- 
szeres hibaészleléssel (SECDED, Single Error Correction 
Double Error Detection). 

A Hi-Bar kapcsolók többsoros elrendezésben is összekap- 
csolhatók, lehetővé téve, hogy két sor 256 csomópontot ke- 
zeljen. Minden Hi-Bar kapcsoló egy 2U magas, 19 hüvelyk 
széles keretszerelésű készülékházban foglal helyet a táp- 
egységével és a hűtőrendszerével együtt, így könnyen 
beépíthető a kiszolgálókeretekbe. 

A Hi-Bar kapcsolókkal megvalósított összekapcsolást 
használó SRC-kiszolgálók egyesítik a közös memória 
csomópontokat a mikroprocesszorokkal és a MAP-ekkel. 
Minden egyes közös memória csomópont saját intelligens 
DMA-vezérlővel és akár 8 GB DDR SDRAM-mal rendel- 
kezik. Az SRC-6 MAP-, SNAP- és közös memória csomó- 
pontjai (CM) 64 bites virtuális memóriacímzést használ- 
nak a rendszerben lévő összes memória címzéséhez, ami 
lehetővé teszi az alkalmazások számára, hogy egyetlen 
egybefüggő memóriaként kezeljék a teljes rendelkezésre 
álló tárterületet. Minden csomópont 1.4 GB/s elsőbbségi 
írási és olvasási átviteli sebességgel rendelkezik. 

A CM intelligens DMA-vezérlője olyan összetett DMA- 
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műveletek végrehajtására is képes, mint az adattömörítés, 
lépdelő adatelérés éss a szórás/összegyűjtés a rendszer 
belső sávszélességének minél hatékonyabb kihasználására. 
A belső kapcsolatok hatékonysága tízszer akkora, mint 

az átmeneti tárhelyekre épülő mikroprocesszoré, amely 
ugyanezt az ilyen műveletekhez általánosan használt 
kapcsolatot alkalmazza. 

Ráadásul az SRC közös memória csomópontjai kizárólagos 
szemafor-kapcsolással rendelkeznek, amely szintén elérhető 
Az összes MAP-processzor és mikroprocesszor számára 

a szinkronizáláshoz. 


Az átszerkeszthető számítási mód programozási modellje 
Az RC programozási modellje a hagyományos elgondo- 
lás szerint egy hardvertervezési szempont. Mivel az RC 
alapját képező FPGA-technológia által megkövetelt esz- 
közök az elektronikai tervezési iparból származnak, egy 
szoftverfejlesztő tényleg nem sok eszközt találhatott isme- 
rősnek ezen a területen. Az eszközök az olyan hardverleíró 
nyelveket (HDL) támogatták, mint a Verilog, VHDL és 

a Schematic Capture. 

A SOC-rendszerek (system-on-a-chip, egylapkás 
összetettebbé váló hardverleíró meghatározásokkal 
elérhető közelségbe kezdtek kerülni a magasszintű 
programozási nyelvek. A Java és C-szerű nyelvek hasz- 
nálata egyre általánosabb az RC-lapkák programozása 
terén. Ez egy nagymértékű előrelépést jelent, ami azon- 
ban az alkalmazásprogramozóktól is jelentős mértékű 
váltást követel. 

Az SRC-programozási modell egy hagyományos prog- 
ramfejlesztő modell, amelyben a MAP-processzor progra- 
mozására a C és a Fortran használatos, és bármely nyelv, 
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amely összeköthető a futásidejű (C-ben 

írt) programkönyvtárakkal, lefordítható 

és futtatható a rendszer mikroprocesszo- 
ros részén. 

Az SRC Carte programozói környezet az- 
zal a tervezői feltételezéssel készült, hogy 
az alkalmazásfejlesztők az RC platformra 
fogják fejleszteni és átültetni a programjai- 
kat. Emiatt az SRC-6 rendszerre való fej- 
lesztés során a hagyományos fejlesztési 

és tervezési elvek érvényesülnek, 

a magasszintű programnyelven (HLL) 

való kódolás, a programfordítás, a szabvá- 
nyos hibakeresővel való ellenőrzés, a kód 
javítása. Csak amikor már hiba nélkül 

fut az alkalmazás egy mikroprocesszoros 
környezetben, akkor kerül sor a program 
DEL-processzorra, a MAP-re történő 
átfordítására. 

Egy RC-rendszerre történő programfordítás 
két olyan lépésből áll, amely meglehetősen 
idegen az utasításvégrehajtó processzorra 
történő programozáshoz képest. A HLL- 
fordítóprogram kimenetének egy hardver- 
definíciós nyelvnek kell lennie. A Carte-ben 
ez vagy a Verilog vagy az EDIF (Electronic 
Design Interchange Format, elektronikus ter- 
vezés adatcsere-formátuma). Az EDIF-fájlok azok a hardver- 
leíró objektumfájlok, amelyek az RC-lapkákban megvalósí- 
tott áramköröket írják le. Ha a kimenet Verilog, akkor ezt 

a HDL-t EDIF formátumúra kell hozni egy olyan Verilog- 
fordítóval mint a Synplicity Synplify nevű programja. 

Egy utolsó lépés, az elhelyezés és útvonalkijelölés, veszi az 
EDIF-tájlokból álló készletet és létrehozza az RC lapkán az 
áramkörök fizikai elrendezését. A folyamat bemeneti fájljai 
olyan konfigurációs bitfolyamok, amelyek az FPGA-ba 
tölthetők az RC-processzorba programozandó algoritmus 
hardveres kialakításának létrehozása céljából. 

A C vagy Fortran nyelvből az FPGA által használható 
bitfolyammá történő fordítást a Carte programozói környe- 
zet végzi el anélkül, hogy a programozónak a folyamatba 
bele kellene avatkoznia. A program a mikroprocesszorokba 
szánt kódokat tovább fordítja objektummodulokká. 

A Carte számára az utolsó lépés annak az egységesített 
futtatható fájlnak a létrehozása, amely egyetlen linuxos 
futtatható fájllá olvassza össze a mikroprocesszor objektum- 
moduljait, a MAP-bitfolyamokat, és az összes szükséges 
futtatói programkönyvtárat. A 6. és 7. ábrán a Carte fordító- 
folyamatát láthatjuk. 


Sebesség 


A nyílt forráskód hardver-lehetőségei 

A Linux élen járt és jó hasznot húzott a nyílt forráskód 
mozgalmából, amelynek során a programfejlesztők egy 
elkötelezett csoportja létrehozta, és továbbfejlesztette 

a Linux rendszermagját, mégpedig az újítások és minőség 
olyan szintjén, ami nem mérhető egyetlen kereskedelmi 
programokkal foglalkozó vállalathoz sem. Az átszerkeszt- 
hető számítási módban megvan annak a lehetősége, hogy 
a hardver tervezési szintjén használja ki ezeket az újításo- 
kat és technikai előnyöket. Ennek a cikknek a jelentős 


2005. július 23 


KIE LEAATGAT 


0 Kiskapu Kft. Minden jog fenntartva 








Szaktekintély 


0 Kiskapu Kft. Minden jog fenntartva 





része azzal foglalkozik, hogy bemutassa azt az elvet, 
ahogyan az alkalmazások programozói a szabványos 
programozói eljárásokat használva hozzák létre az alkal- 
mazástól függő hardvert, anélkül, hogy ismerniük kellene 
a hardver felépítését. Az RC-ben ennek ellenére az alkal- 
mazásprogramozók által létrehozott építőelemek a funk- 
cionális egységek. Ezek az egységek olyan számítási alap- 
műveleteket végeznek, mint az összeadás, lebegőpontos 
szorzás vagy a trigonometrikus függvények. A funkcionális 
egységek ezen felül lehetnek olyan speciális nagyteljesít- 
ményű egységek is, mint a háromszoros titkosítást 

(DES) megvalósító függvény vagy egy olyan, nem szabvá- 
nyos pontosságú aritmetikai egység, mint a 24 bites IEEE 
lebegőpontos operátorok. 

A funkcionális egységeket a logikai tervezők hozzák létre. 
Az RC-fordítóprogramok, mint amilyen az SRC Carte 
MAP fordítója, képesek arra, hogy lehetőséget biztosítsa- 
nak a fordítóprogram által támogatott szabványos operá- 
torok mellett felhasználó által létrehozott funkcionális 
egységek hozzáadására. Ha ilyen újszerű és erede- 

ti funkcionális egységeket teszünk elérhetővé az alkalma- 
zásprogramozók számára, még nagyobb teljesítmények 
válhatnak elérhetővé. 

A funkcionális egységek újszerű hardverfelépítésének létre- 
hozása az a terület, ahol a nyílt hardver mozgalom jelentős 
előrelépést hozhat a számítástudományba. Az újítás és ter- 
mékenység, amit a nyílt forráskód területén tapasztalhat- 
tunk, most a nyílt hardver köntösében jelenhet meg újra. 
Az RC még nagyon sok kreatív tervezőnek kínál esz- 

közt arra, hogy új és eredeti hardvert hozzon létre, 

amit azután az alkalmazásfejlesztők hasznosíthatnak. 

Az Opensources.org-hoz hasonló csoportokon keresztül 
pedig megoszthatók és továbbfejleszthetők ezek a funk- 
cionális egységek. Az a jelentős előny, ami a nyílt forrású 
programoknak köszönhetően a számítástudományban 
megmutatkozott, könnyen jelentkezhet egy nyílt hardverre 
összpontosító mozgalomban is. 


Kódolási példa 

A DEL-processzorban rejlő teljesítményelőnyt egy ka- 
rakterlánc-összehasonlító példán keresztül fogom megvi- 
lágítani. A példákhoz tartozó forráskód letölthető a Linux 
Journal FTP-oldaláról (lásd a kapcsolódó címeket). A példa 
Christian Charras és Thiery Lecrog honlapjáról származik 
és a NIST Dictionary of Algorithms and Data Structures 
(az algoritmusok és adatszerkezetek NIST szótára) hi- 
vatkozik rá. Összehasonlításképpen a , nyers erő" és 

a Boyer-Moore féle karakterlánc-összehasonlító algorit- 
must valósítjuk meg egy 2.8 GHz-es Intel Xeon processzo- 
ron az Intel C4-1- 8.0 Linuxos fordítóprogramjával. 

A ,nyers erő" algoritmust az SRC-rendszerhez a Carte 1.8 
verziójú programozói környezettel állítjuk elő. A ,nyers 
erő" algoritmus egy egyszerű karakterenkénti összehason- 
lítást végez a karakterlánc és a minta között. A Boyer- 
Moore algoritmust tekintik a leghatékonyabb karakter- 
láncösszehasonlító eljárásnak. A példában egy 20 MB-os 
véletlenszerűen előállított szövegben keresünk hat illetve 
tíz mintát. A fordításokat -O3 optimalizáló beállítással 
végeztük. Az összehasonlító eredményeket az 1. táblázat 
tartalmazza. További keresési mintákat adva a feladathoz 
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a mikroprocesszor végrehajtási ideje megnövekszik, 
azonban a MAP futási idejére nincs hatással, köszönhető- 
en a párhuzamos végrehajtásnak. Bár a Xeon 2,8 GHz-en 
fut, a MAP pedig 100 MHz-en, a DEL párhuzamossága 
mégis 99-szeres teljesítményelőnyt biztosít a MAP számá- 
ra. A példa a MAP egyetlen FPGA-jának 6070-át vette 
igénybe. Egy kétlapkás összeállítás több mint 200-szoros 
teljesítményt eredményezne. 

Annak a bemutatására, hogy egy további számítás hoz- 
záadása a csővezetékkel ellátott ciklushoz miként befo- 
lyásolja a teljesítményt és hogy szemléltetni tudjam az 
egyedi funkcionális egységek képességeit, egy másik 
összehasonlítást is elvégeztem, amelyben a keresési eljá- 
rás egy DES-titkosítással kódolt szöveggel teszteltem. 

A szöveget a keresés előtt dekódolni kell. A MAP megva- 
lósításban egy DES csővezetékes egységet alkalmaztam. 
A Verilog nyelvű leírás az Opencores.org oldalról szárma- 
zik, ezt építettem be a keresési ciklusba. Mivel a ciklus 
csővezetéket alkalmaz, órajelenként egy egész eredmény- 
halmazt szolgáltat. Emiatt a 20 MB-os szövegben való 
keresés és a DES-dekódolás becsült ideje nem változik 

a keresések számának növelésével. Ez vezet a megdöb- 
bentő 232-szeres sebességnövekedéshez a mikropro- 
cesszoros megoldással szemben. A 10 mintás keresés 
MAP megvalósítása csak az FPGA teljesítményének 7079- 
át vette igénybe, így egy kétlapkás felépítés 460-szoros 
többletet eredményezne. 

A Xeon processzoron megvalósított dekódolás 

Stuart Levy (Minnesota Supercomputer Center) optimali- 
zált kódját alkalmazta. 


Osszegzés 

Cikkemben elmagyaráztam az átszerkeszthető számítási 
mód elvét, valamint példákat mutattam a módszerekre és 
az elérhető eredményekre. Látható, hogy nagyon jelentős 
teljesítménytöbblet érhető el ilyen módon. Jelenleg az RC 
nagymértékben hozzájárulhat a számítástudomány további 
fejlődéséhez és a jövő is sokkal többet tartogat a számunk- 
ra, mint az a mikroprocesszorok fejlődésének Moore- 
törvénye alapján várható lenne. Az RC már most elérhető 
a programozók számára, akik használhatják a megszokott 
fejlesztői modellt, és egy olyan keretrendszer is rendel- 
kezésre áll, amellyel a hardvertervezők szélesebb köre is 
bekapcsolódhat a nagyteljesítményű számításokba a nyílt 
forrás biztosította kreativitás és alkotóerő kihasználásával. 
Az RC már hosszú ideje jelen van, a jelenlegi szoftver- és 
hardvertechnológia megteremtette annak a lehetőségét, 
hogy minden számítógépnek a részévé váljon a beépített 
processzoroktól a Peta-Scale szuperszámítógépekig. 


Linux Journal 2005. január, 129. szám 
Kapcsolódó címek: 5 www.linuxjournal.com/article/7867 


Dan Poznanovic (pozosrccomp.com) a szoftver- 
fejlesztés vezetője az SRC Computers-nél. 

A nagyteljesítményű számítások kutatásában 
1987 óta vesz részt, amikor a Cray Research 
céghez csatlakozott. 








ATA Over Ethernet: merevlemezek a helyi hálózaton 


Napjainkra az ATA felületű merevlemezek olcsóbbak lettek, mint a szalagok, 
a címben szereplő egyszerű, új megoldással pedig archívumok, biztonsági 
mentések vagy éles használat céljára építhetünk tárolótömböket. 


lőbb-utóbb mindenki kifogy a tárolóhelyből. Szeren- 
E csére a merevlemezek egyre olcsóbbak, miközben 

kapacitásuk folyamatosan növekedik. Hiába azon- 
ban a több hely, hiszen egyre többet használunk el, így újra 
szűkébe kerülünk. 
Bizonyos adatfajták természetüknél fogva méretesek. 
A mozgóképek például mindig nagy mennyiségű helyet 
foglalnak. A vállalkozásoknak sokszor kell mozgóképeket 
tárolniuk, különösen, mióta elkezdődött a videómegfigyelő 
rendszerek térnyerése. Sőt, még otthoni gépükön is sokan 
szeretnek filmeket nézni vagy szerkeszteni. 
A biztonsági mentés és a redundancia minden számítógé- 
peket használó vállalkozás számára fontos fogalom. A való- 
ság nagyjából az, hogy bármennyi tárolókapacitásunk is 
van, sose árt még egy kicsit több. Elég csak arra gondolni, 
hogy még az elektronikus leveleknek szánt tárolóhely is 
folyton kevés - az internetszolgáltatók bizonyára tudnának 
erről mesélni. 
A korlátlan tárolóhely akkor válhat valósággá, ha a meghaj- 
tók kikerülnek a számítógépházból, és ezzel a tárolóeszkö- 
zök függetlenekké válnak az őket használó számítógépektől. 
A rugalmasságnak az egymással együttműködő összetevők 
szétválasztásával elért növelésére több területen is láthatunk 
példát, nem csak az adattárolásén. A moduláris forráskód 
rugalmasabban használható az előre nem látott igények ki- 
elégítésére, és egy több részből álló sztereó rendszer is érde- 
kesebb összeállításokban telepíthető, mint egy mindent 
egyetlen dobozban tartalmazó. 
A leginkább ismert példa a készen kapható adattárolásra ta- 
lán a tárolóhálózat (storage area network, SAN). Emlékszem, 
amikor a SAN-ok megjelentek, hatalmas zsongás vette őket 
körül, és elég nehéz volt kideríteni, hogy valójában mik is. 
Amikor végre sikerült, csalódottan kellett tudomásul ven- 
nem, hogy a SAN-ok bonyolultak, egy-egy gyártóhoz kö- 
tődnek és drágák. 
A SAN-ok támogatása érdekében a linuxos közösség 
mindennek ellenére fontos módosításokat hajtott végre 
a rendszermagban. A 2.6-os rendszermag újdonságainak 
jelentős részét a 2.4-es rendszermagsorozat nagyvállalati 
használatra szánt tagjainak szolgáltatásai ihlették, és nap- 
jaink üzembiztos rendszermagjai számos olyan dolgot 
tudnak, amit néhány éve még nélkülöznünk kellett. 
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Például hatalmas kapacitású blokkos eszközöket hasz- 
nálhatunk, messze túlnyúlva a régi két TB-os határon, 

és nagyobb számú lemez egyidejű csatlakoztatása sem 
okozhat gondot. Szintén fontos fejlesztés a tárolókötetek 
kifinomult kezelése, ahogy a fájlrendszerek is hatalmas 
méretűekre hízhatnak, akár becsatolt állapotban, haszná- 
lat közben is. 

írásomban ismertetem, hogyan aknázhatjuk ki a rendszer- 
mag új szolgáltatásaiban rejlő lehetőségeket, hogyan vehet- 
jük ki a lemezeket a számítógépekből, és hogyan léphetünk 
túl a tárolók használatával és kapacitásával kapcsolatos 
korábbi korlátokon. Az ATA over Ethernetet (ATA Ethernet 
felett, AoE) talán úgy szemlélhetjük, mint megoldást arra, 
hogy az IDE kábel helyére egy Ethernet hálózat kerüljön. 
Ha az adattárolást leválasztjuk a számítógépről, és kihasz- 
náljuk a két rendszerelem közötti Ethernet rugalmasságát, 
akkor a lehetőségeket csupán képzelőerőnk és új dolgok 
elsajátítására irányuló hajlandóságunk végessége fogja 
korlátozni. 


Mi az AoE? 

Az ATA over Ethernet egy az IEEE-nél 0x88a2 azonosí- 
tóval bejegyzett Ethernet hálózati protokoll. Az AoE 
alacsony szintű, jóval egyszerűbb a TCP/IP-nél, sőt, 

az IP-nél is. A TCP/IP és az IP az internet esetében 
fontos megbízhatóságot növelő feladatokat lát el, 

ám a számítógépeknek komoly munkát jelent az ebből 
fakadó bonyolultság kezelése. 

Az iSCSI-t használóknak nyilván ismerős ez a TCP/IP-vel 
kapcsolatos gond. Az iSCSI egy másik megoldás be- és 
kivitelek TCP/IP feletti továbbítására, segítségével olcsó 
Ethernet készülékekkel lehet helyettesíteni a költséges Fibre 
Channel berendezéseket. Sok iSCSI-használó TCP teher- 
mentesítő motorokat (TCP offload engine, TOE) kezdett 
vásárolni. A TOE kártyák olcsók, és alkalmasak arra, 

hogy az iSCSI-t használó gépek válláról levegyék a TCP/IP 
kezelésének terhét. 

Érdekes megfigyelés, hogy a gyakorlatban a legtöbb 
esetben az iSCSI-t nem internet felett használják. Ha a cso- 
magoknak egyszerűen a szomszéd szekrényben található 
gépbe kell befutniuk, akkor a nehézsúlyú TCP/IP protokoll 
használata túlzásnak tűnik. 
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A TCP/IP tehermentesítés helyett tehát nem volna jobb, 
ha teljesen elhagynánk az internetes protokollt? Az ATA 
over Ethernet protokoll pontosan ezt teszi, kihasználva 

a napjainkban kapható olcsó kapcsolók által kínált lehető- 
ségeket. A korszerű kapcsolók képesek a folyamvezérlés- 
re, maximális átviteli sebességet és minimális csomagüt- 
közést biztosítva. A helyi hálózaton (local area network. 
LAN) a csomagok sorrendje nem változik meg, és a háló- 
zati hardver minden csomag sértetlenségét ellenőrző 
összeggel védi. 

Minden AoE-csomag vagy egy ATA meghajtónak szóló pa- 
rancsot, vagy egy ATA meghajtótól érkező választ hordoz. 
A Linux rendszermag AOoE illesztőprogramja minden AoE- 
műveletet elvégez, és a távoli lemezeket normál, blokkos 
eszközökként teszi elérhetőkké, ilyen például a /dev/etherd/ 
e€0.0. Az IDE illesztőprogram hasonlóan gondoskodik az 
IDE kábel végén található helyi meghajtó például /dev/hda 
alatti elérhetőségéről. Az illesztőprogram szükség esetén 

a csomagok újraküldését is elvégzi, vagyis az AoE eszközök 
a rendszermag többi része számára tökéletesen egyenérté- 
kűek a többi lemezzel. 

Az ATA parancsok továbbítása mellett az AoE lekérdező 
csomagokkal a rendelkezésre álló AoE eszközöket is képes 
egyszerű módon azonosítani. Ennyi is az egész: ATA pa- 
rancscsomagok és lekérdező csomagok. 

Aki már dolgozott SAN-nal, vagy legalábbis tanult az 
ilyen rendszerekről, bizonyára megdöbbenve mered 
maga elé: ha minden lemez a LAN-ra csatlakozik, hogyan 
lehet korlátozni az elérésüket? Vagyis hogyan biztosítha- 
tó, hogy az A gép feltörése után a B gép lemezei bizton- 
ságban maradjanak? 

A válasz onnan indul, hogy az AoE nem irányítható. 

Azt, hogy mely számítógépek mely lemezeket látják, 
egyszerűen, alkalmi (ad hoc) Ethernet hálózatok összeállí- 
tásával határozhatjuk meg. Mivel az AoE készülékek nem 
rendelkeznek IP-címmel, nem okoz nehézséget az elszi- 
getelt Ethernet hálózatok létrehozása. Egyszerűen adjunk 
áramot a kapcsolónak, majd csatlakoztassuk hozzá a kí- 
vánt rendszerelemeket. Emellett sok újabb kapcsoló kapu 
alapú VLAN szolgáltatást is nyújt, amivel a kapcsolót ha- 
tékonyan lehet különálló, egymástól elválasztott szórási 
tartományokra osztani. 

Az AoE protokoll annyira egyszerű, hogy olcsó vassal 

is használható. Jelenleg a Coraid az egyetlen gyártó, 
mely AoE eszközöket kínál, ám várható, hogy hamaro- 
san további gyártók és alkalmazásfejlesztők is felfede- 

zik majd, hogy az AoE leírása csupán nyolc oldal 

hosszú. Érdemes ezt az egyszerűséget szembeállítani 

az iSCSI több száz oldalas, többek közt titkosítási szol- 
gáltatásokat, forgalomirányítást és felhasználó alapú 
hozzáférés-kezelést taglaló leírásával. A bonyolultság 
mindig költséggel jár, és most már választhatunk, 

hogy igényeljük ezt a bonyolultságot, vagy inkább 
megtartjuk az árát. 

A legegyszerűbb eszközök is lehetnek hatásosak. 

A Linux-felhasználók számára aligha újdonság, hogy 
egyszerűsége ellenére az AoE lehetőségek elképesztő 
választékát kínálja, ha az adattárolás egyszer átkerült 

a hálózatra. Nézzünk tehát egy tényleges példát, majd 
vizsgáljuk meg a lehetőségeket. 
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Stan, a levéltáros 

A következő példa igaz történetre alapul. Stan egy képzelt 
rendszergazda, aki a helyi önkormányzatnak dolgozik. 

Az új rendelkezések szerint minden hivatalos dokumentu- 
mot maradandóan archiválni kell. A város bármely polgára 
bármikor betekintést kérhet bármelyik dokumentumba. 
Stannek tehát hatalmas és korlátok nélkül bővíthető 
tárolóhelyre van szüksége, ugyanakkor a tárolóeszköz tel- 
jesítményének nem kell jobbnak lennie, mint egy átlagos, 
helyi, ATA felületű lemezének. Célja az, hogy minden ada- 
tot könnyen és gyorsan elő lehessen keresni. 

Stan ismeri az Ethernet hálózatokat és a linuxos rendszere- 
ket, ezért az ATA over Ethernet kipróbálása mellett dönt. 
Vásárol néhány eszközt; összesen kevesebb mint 6500 
dollárt fizetve az alábbiakért: 


e Egy darab kétkapus Ethernet kártya, a kiszolgáló régi, 
100 Mbps sebességű kártyája helyett 


e Egy darab 26 kapus hálózati kapcsoló kettő darab 
gigabites kapuval 


e Egy darab Coraid EtherDrive polc és tíz darab 
EtherDrive fiók 


e — Tíz darab 400 GB-os ATA meghajtó 


A tíz fiókot befogadó polc három egység magas. Minden 
EtherDrive fiók egy-egy kisméretű számítógép, mely az AoE 
protokoll kezelésével hatékony módon illeszt a hálózatra 
egy-egy ATA lemezt. Az adatokat csíkozással elosztva a polc 
fiókjai között hasonló teljesítményt kapunk, mint helyi ATA 
meghajtókkal, tehát a gigabites összeköttetéssel hatékonyan 
ki tudjuk használni a rendelkezésünkre álló átviteli kapaci- 
tást. Bár Stan megtehette volna, hogy az EtherDrive fióko- 
kat ugyanarra a hálózatra csatlakoztatja, amire mindenki 
más is kapcsolódik, ám biztonsági és teljesítménybeli szem- 
pontok miatt inkább úgy döntött, hogy a tárolórendszert 
külön hálózatra helyezi, és a kiszolgáló második kapujához, 
az eth1 csatolóhoz kapcsolja. 

Stan átolvassa a Linux Software RAID HOGYAN-t 

(lásd az internetes forrásokat), majd úgy határoz, hogy 
RAID 10 csíkozást használ, tükrözött lemezpárok felett. 

Bár ezzel a megoldással kevesebb tárkapacitást kap, mint- 
ha RAID 5-öt használna, viszont a RAID 10 a lehető leg- 
jobb megbízhatóságot nyújtja, miközben a processzorra 

a RAID kezelése miatt háruló többletterhelés minimális 
marad, valamint a tömb újraépítése is rövidebb ideig tart, 
ha egy-egy lemez kiesik. 

Az LVM HOGYAN (lásd a forrásokat) átolvasása után Stan 
kidolgoz egy tervet, amellyel elkerülheti, hogy valaha is el- 
fogyjon a szabad tárhely. A JES fájlrendszer képes dinami- 
kusan méreteződni akár egészen nagyra is, vagyis Stan JFS-t 
tesz egy logikai kötetre. A logikai kötet ebben az esetben 
csak egy fizikai kötetre terjed ki, ez pedig a RAID 10 blokkos 
eszköz lesz. A RAID 10 a Coraid polcban lévő EtherDrive fió- 
kokból jön létre, a Linux szoftveres RAID megoldásával. 

Ha később újabb polcra lesz szüksége, akkor majd létrehoz 
egy másik RAID 10 készletet, abból lesz egy fizikai kötet, 
amelyre kiterjeszti a JFS-t tartalmazó logikai kötetet. 


1. kódrészlet Egy nagyszámú AoE meghajtóból 
álló szoftveres RAID eszköz létrehozásának első lépése 
az AoE telepítése, beállítása 


tf A gazdagép beállítása AoE használatára 
ft az AoE illesztőprogram lefordítása 

ft és telepítése 

tar xvfz aoe-2.6-5.tar.gz 


cd aoe-2.6-5 
make AOE PARTITIONS-1 install 
tf Az AoE nem igényel IP-címet!  :) 


ifconfig ethl up 

tf A hálózati csatoló felélesztése 

sleep 5 

f Az ATA over Ethernet illesztőprogram betöltése 
modprobe aoe 

tf A rendelkezésre álló AoE lemezek megtekintése 
aoe-stat 


Az 1. kódrészlet azokat a parancsokat tartalmazza, amelyeket 
Stan a kiszolgáló ATA over Ethernet előkészítésére használ. 
Az AoE illesztőprogramot az AOE. PARTITIONS-1 átadott 
értékkel fordítja le, ugyanis 2.6-os rendszermagot futtató 
Debian sarge rendszere van. A sarge jelenleg nem támo- 
gatja a nagyobb értékű eszköz-alazonosítókat (lásd az 
Alazonosítók című széljegyzetet), ezért kikapcsolja a leme- 
zek részekre osztásának támogatását, így ugyanis több le- 
mezt tud használni. Figyelembe véve a Debian 292070-es 
számú hibáját, Stan telepíti a legújabb eszközleképezőt 

és az LVM2 felhasználói programokat. 


Alazonosítók 

Ha egy program használni akar egy eszközt, akkor ezt 
jellemzően az eszközhöz tartozó különleges fájl megnyitá- 
sával teszi. Jól ismert példa a /dev/hda fájl. Ha kiadjuk az 

1s -1 parancsot, akkor a /dev/hda esetében két számot 
látunk, ezek a 3 és a 0. A /dev/hda1 fájl alazonosítója 1, 
főazonosítója viszont szintén 3. 

A 2.6-os rendszermag megjelenése előtt az alazonosító áb- 
rázolása nyolc biten történt, vagyis értéke 0 és 255 között le- 
hetett. Mivel senkinek nem volt ilyen sok eszköze, a korlát 
tulajdonképpen senkit nem zavart. Most, hogy a lemezeket 
le lehet választani a kiszolgálókról, megváltozott a helyzet, 
ezért a 2.6-os rendszermag már 20 biten ábrázolja az eszkö- 
zök alazonosítóját. 

Így az alazonosító 1048576-féle értéket vehet fel, ami nagy se- 
gítség ahhoz, hogy a rendszerekhez nagyszámú eszközt tud- 
junk csatlakoztatni — csakhogy a változást nem minden prog- 
ram követte. Ha a glibc vagy valamelyik alkalmazás azt hiszi, 
hogy az alazonosítók még mindig nyolcbitesek, akkor gond- 
jaink lesznek a 255-nél nagyobb alazonosítók használatával. 
Az átmenetet segíti, hogy az AOE illesztőprogramot a le- 
mezrészek támogatása nélkül is le lehet fordítani. Ilyenkor 
egy-egy lemezhez 16 helyett csak egyetlen egy alazonosító 
tartozik. Nem baj tehát, ha a rendszer nem ismeri még 

a 2.6-os nagyméretű eszköz-alazonosítóit, akár 256 AoE 
lemezt is használhatunk. 
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2. kódrészlet A szoftveres RAID és az LVM 
kötetcsoport beállítása 


ft A RAID kezdeti értékadásának felgyorsítása 

for f in find /proc I grep speed ; do 
echo 100000 5 $f 

done 

$ Tükrök létrehozása (az mdadm kezeli a forró 

$ tartalékokat) 

mdadm -C /dev/md1 -1 1-n2Y 
/dev/etherd/e0.0 /dev/etherd/e0.1 

mdadm -C /dev/md2 -1 1-n2YV 
/dev/etherd/e0.2 /dev/etherd/e0.3 

mdadm -C /dev/md3 -1 1-n2YV 
/dev/etherd/e0.4 /dev/etherd/e0.5 

mdadm -C /dev/md4 -1 1 -n 2 -xX2YN 
/dev/etherd/e0.6 /dev/etherd/eO0.Z XN 
/dev/etherd/e0.8 /dev/etherd/e0.9 

sleep 1 

$ A csík létrehozása a tükrök felett 

mdadm -C /dev/mdO -1 0 -n4N 
/dev/md1 /dev/md2 /dev/md3 /dev/md4 

f A RAID 10 megfeleltetése LVM fizikai kötetnek 

pvcreate /dev/mdO 

$ Bővíthető LVM kötetcsoport létrehozása 

vgcreate ben /dev/mdO 

tt A fizikai kiterjedés vizsgálata 

vgdisplay ben ] grep -i "free."PE"? 

$ A teljes helyre kiterjedő logikai kötet 

$ létrehozása 

1lvcreate -extents 88349 -name franklin ben 

modprobe jfs 

mkfs -t jfs /dev/ben/franklin 

mkdir /bf 

mount /dev/ben/franklin /bf 


A fájlrendszer és a logikai kötet létrehozására használt 
parancsokat a 2. kódrészlet tartalmazza. Stan a kötet- 
csoportnak a ben, a logikai kötetnek pedig a franklin 
nevet adja. Ezután módosítania kell néhány dolgot 

az LVM2 beállításaiban. Először is, szükség lesz egy 
types - [ "aoe", 16 ] sorra, ami lehetővé teszi, hogy 
az LVM felismerje az AoE lemezeket. Ugyancsak szükség 
van az md. component. detection - 1 sorra, amelynek 
hatására a gép a RAID 10 készleten belüli lemezeket 
figyelmen kívül hagyja, miután a teljes RAID 10 készlet 
egyetlen a fizikai kötetet alkot. 

Stan rendszerét magam is összeállítottam, Debian 

sarge operációs rendszerrel, kettő darab 2,1 GHz-es 
Athlon MP processzorral, 1 GB memóriával és egy 
Intel PRO/1000 MT kétkapus hálózati kártyával, ma 
már elavulófélben lévőnek számító 40 GB-os meghaj- 
tókkal. Hálózati kapcsolóként egy Netgear FS5Z6T készü- 
léket használtam. Ha a RAID 10 készletet nyolc darab 
EtherDrive fiókra terjesztettem ki, akkor 23,58 MBps 
folyamatos olvasási és 17.45 MBps folyamatos írási 
sebességet sikerült elérnem. A mérések elvégzése előtt 
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3. kódrészlet Leválasztása nélkül úgy tudjuk bővíteni 
a fájlrendszert, hogy létrehozunk egy második RAID 10 
készletet, hozzáadjuk a kötetcsoporthoz, majd kiterjeszt- 

jük a fájlrendszert 


ft A második polc RAID 10 készletét 

ft létrehozása után 

ft /dev/md5-ként adjuk hozzá a kötetcsoporthoz 
vgextend ben /dev/md5 

vgdisplay ben ] grep -i "free."PE" 

ff A logikai kötet majd a jfs megnövelése 
1lvextend -extents -88349 /dev/ben/franklin 
mount -o remount, resize /bf 


egy 1 GB-os fájlt a /dev/nullba másolva kiürítettem 

a gyorsítótárat, az írási időbe pedig egy sync parancs 
végrehajtását is belevettem. 

Ebben az esetben a RAID 10 készletnek négy csíkeleme 
volt, mindegyik egy pár tükrözött meghajtóból állt. Általá- 
nos esetben egy EtherDrive fiókokból álló készlet átviteli 
sebességét a csíkelemek száma alapján tudjuk megbecsülni. 
Egy RAID 10 készletben feleannyi csíkelem van, mint le- 
mez, hiszen minden lemez tükrözve van egy másikra. 

A RAID 5 esetében egy lemez tárolja a paritásadatokat, 

a több lemez pedig csíkelemként veendő figyelembe. 

A várható olvasási sebesség a csíkelemek száma szorozva 

6 MBps-mal. Ha tehát Stan a nyolc fiókból álló RAID 10 
készlet helyett két polcot vásárolt volna, és a készletet 18 
meghajtóból állította volna össze, akkor valamivel több, 
mint kétszer ekkora átviteli sebességet kapott volna. Stan 
azonban nem igényel ekkora átviteli sebességet, és egy 
viszonylag kisméretű, 1,6 TB-os fájlrendszer is megfelel 

az igényeinek. 

A 3. kódrészlet azt szemlélteti, hogy Stan milyen könnyen ki 
tudja bővíteni a fájlrendszert, ha vásárol egy második pol- 
cot is. A kódrészletben Stan mdadm-aoe.conf fájlja és indító 
és leállító parancsfájljai nem szerepelnek. A figyelő módban 
futó mdadm folyamattal az mdadm beállító fájl közli a forró 
tartalékok kezelési módját, így ezekkel bármikor helyettesí- 
teni lehet bármelyik meghibásodott tükör bármelyik meg- 
hajtóját. Lásd még az mdadm man oldalának tartalékcsopor- 
tok (spare groups) című részét. 

Az indító és leállító parancsfájlokat könnyen össze lehet 
állítani. Az indító parancsfájl egyszerűen összeállítja a tük- 
rözött RAID 1 majd a RAID 0 készleteket, végül elindít egy 
mdadm figyelő folyamatot. A leállító parancsfájl leállítja az 
mdadm figyelőt, melyet követően leállítja először a RAID 0, 
majd a tükrözött készleteket. 


Blokkos tárolóeszköz megosztása 

Láttuk, hogyan működik az ATA over Ethernet, és az ol- 
vasóban bizonyára felmerül a kérdés: vajon mi történik, 
ha egy másik állomás is hozzá szeretne férni a tárolóháló- 
zathoz? Van arra lehetőség, hogy a második állomás is 
betfűzze a JFS fájlrendszert, és hozzáférjen ugyanazokhoz 
az adatokhoz? Nos, biztonságosan erre nincs mód. A JFS-t 
az ext3-hoz és a többi fájlrendszer túlnyomó részéhez 
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hasonlóan egyetlen állomással való használatra tervezték. 
Az ilyen ,egygépes" fájlrendszerek megsérülhetnek, ha 
ugyanazt a blokkos tárolóeszközt több állomás is befűzi. 
Ennek oka a puffer gyorsítótárban keresendő, ami a 2.6-os 
rendszermagokban egyesítve van a lapgyorsítótárral. 

A Linux meglehetősen rámenős módon, minden lehetősé- 
get megragadva gyorsítótárazza a fájlrendszer adatait 

a memóriában, kerülve a lassú blokkos tárolóeszközök 
használatát, és ezzel javítva a teljesítményt. 

A gyorsítótárazás hatékonyságáról bárki meggyőződhet, 
ha kétszer egymás után lefuttat egy find parancsot 
ugyanazon a könyvtáron. 

Bizonyos fájlrendszereket úgy terveztek, hogy több állomás 
is használhassa őket. Az úgynevezett fürtfájlrendszerek pél- 
dául megfelelő eljárásokat tartalmaznak annak biztosítására, 
hogy az összes állomás gyorsítótára összhangban maradjon 
a fájlrendszerrel. Kiváló példa erre a nyílt forrású GFS. 

A GES külön fürtkezelő programot használ annak követésé- 
re, hogy ki szerepel a fájlrendszert használó állomások cso- 
portjában. A fájlrendszert elérő állomások együttműködését 
zárak segítségével biztosítja. 

Fürtfájlrendszer, például GFS használatával megoldható, 
hogy az Ethernet hálózat több állomása is használhassa ATA 
over Ethernet felett ugyanazt a blokkos tárolóeszközt. Ilyen- 
kor nincs szükség például NFS-kiszolgálóra, hiszen mind- 
egyik állomás közvetlenül, a be- és kiviteleket szépen eloszt- 
va éri el a tárolóeszközt. Van azonban egy kis bökkenő. Mi- 
nél nagyobb számú lemezt használunk, annál nagyobb a va- 
lószínűsége annak, hogy az egyik meghibásodik. Ezt a prob- 
lémát általában RAID használatával szokták orvosolni, némi 
redundanciát hozva a rendszerbe. Sajnos a Linux szoftveres 
RAID-je nem képes a fürtök kezelésére. Nincs tehát mód 
arra, hogy a hálózat összes állomása RAID 10 készletet és 
mdadm-et használjon. 

A Linux fürtkezelése ugyanakkor elképesztő tempóban fej- 
lődik. Biztos vagyok abban, hogy egy-két év múlva kiváló, 
fürtképes RAID áll majd rendelkezésünkre. Addig is azon- 
ban más megoldásokat kell keresnünk az AoE alapú fürtök 
megosztására. Az alapötlet az, hogy központosítsuk a RAID 
szolgáltatást. Vásárolhatunk például egy vagy két Coraid 
RAIDBIade vezérlőt, majd a fürtcsomópontokkal az ezeken 
keresztül exportált tárolóeszközt érhetjük el. A RAIDBlade 
vezérlők minden mögöttük lévő EtherDrive fiókot képesek 
kezelni. Ha szeretünk barkácsolni, akkor ugyanezt a felada- 
tot egy linuxos, szoftveres RAID-et futtató géppel is meg- 
oldhatjuk, mely ATA over Etherneten keresztül maga teszi 
elérhetővé a lemezhibáktól mentesített blokkos tárolóesz- 
közt. Például a vblade program (lásd a forrásokat) képes 
tetszőleges tárolóeszközt elérhetővé tenni ATA over 
Etherneten keresztül. 


Biztonsági mentés 

Mivel az ATA over Ethernet olcsó merevlemezeket csatla- 
koztat az Ethernet hálózatra, akár biztonsági mentések 
készítésére is alkalmazható. A mentési stratégia sokszor 
másodvonalbeli adattárolást is magába foglal, vagyis olyan 
tárolóeszközt, amely ugyan nem olyan gyors, mint az éles 
rendszer, de könnyebben hozzáférhető, mint a szalagos. 
Az ATA over Ethernet segítségével olcsó ATA meghajtókat 
használhatunk másodvonalbeli adattároló eszközökként. 











Sót! Ha ilyen olcsó merevlemezeink vannak, és ennyire 
üzembiztos szoftveres RAID-et tudunk alkalmazni, miért is 
ne használhatnánk mentési adathordozóként a merevleme- 
zeket? A szalagokkal ellentétben ezek azonnali hozzáférést 
biztosítanak bármely archivált fájlhoz. 

Sok új biztonsági mentési alkalmazás a fájlrendszerek 
mentési szolgáltatásait is képes kihasználni. Közvetlen 
hivatkozásokkal több teljes mentést is képesek elvégezni, 
a növekményes mentések hatékonyságával. További tud- 
nivalók az internetes források között szereplő Backup PC 
és rsync hivatkozások révén érhetők el. 


Osszefoglalás 

Olcsó merevlemezek közvetlenül a hálózaton - jogos a kér- 
dés, hogyhogy korábban senkinek nem jutott eszébe? Az 
adattárolás a kiszolgálóktól való elválasztását érdemes lehet 
valamilyen egyszerű hálózati protokoll segítségével végez- 
ni, drága eszközök nélkül — még ha az egyszerű protokoll 
használhatósága a helyi Ethernet hálózatra korlátozódik is. 
A helyi hálózaton ugyanakkor nincs is szükség a mindenre 
kiterjedő szolgáltatásokat nyújtó internetes protokollok, 
például a TCP/IP bonyolultságára és többletterhelésére. 

Ha az adattárolást a helyi hálózatra akarjuk korlátozni, 

és az Ethernet hálózatok kiépítése révén kapott hozzáfé- 
résvezérlés kielégíti az igényeinket, akkor az ATA over 
Ethernet számunkra a megfelelő választás. Ha a tárolópro- 
tokolltól titkosítási, irányíthatósági és felhasználó alapú 
hozzáférés-vezérlési szolgáltatásokat várunk, akkor az 
iSCSI-val érdemes barátkoznunk. 


Az ATA over Ethernet olyan egyszerű alternatíva, 

amely eddig egyszerűen hiányzott a linuxos adattárolá- 
si lehetőségek közül. Az egyszerűség egyben lehetősége- 
ket is jelent. Az AoE által biztosított alapra tetszőleges 
adattároló megoldást felépíthetünk. Mindenkit szeretnék 
arra buzdítani, hogy engedje szabadjára a képzeletét, 
majd írja meg nekem, hogy milyen rendszert sikerült 
felépítenie. 
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Ed L. Cashin 1997 óta különféle tudományos 

és linuxos szakmai területekkel foglalkozott, 

volt már webalkalmazás-fejlesztő, rendszergaz- 
da és rendszermag-programozó egyaránt. Jelen- 
leg a Coraid munkatársa, itt történt az ATA over 
Ethernet kifejlesztése. Az ecashinXgcoraid.com 
címen érhető el. Miközben harcművészeti 

óráira tart, legszívesebben zenét és hangos 
könyveket hallgat. 
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A (elektronikus könyvek, e-book) olyan készü- 

lékeken jeleníthetők meg, amelyek általában 
túl kevés erőforrással rendelkeznek egy normál 
webböngésző futtatásához. Sok kiadó, a Project 
Gutenberghez hasonló tervezeteket már nem is említ- 
ve, több ezer új és klasszikus kiadványt jelentetett 
meg digitális formában. Baj egyrészt a hardverrel van 
-— legyen szó akár általános célú zsebtitkárról, akár cél- 
készülékről -, másrészt magával az e-könyvek kiadásá- 
val foglalkozó ágazattal, amely jóval széttöredezettebb, 
mint a személyi számítógépek és a webböngészők piaca. 
Lehet tehát, hogy megveszünk ma egy e-könyvet, 
és tíz év múlva már nem tudjuk elolvasni -— sőt, lehet, 
hogy már holnap sem, ha például új hordozható gé- 
pet vagy zsebtitkárt vásárlunk. Mivel a széttagoltság 
elleni fellépés sokak érdeke, írásomban néhány olyan 
parancssori eszközt szeretnék ismertetni, amelyek se- 
gítségével a népszerűbb formátumú e-könyveket ASCII 
vagy HTML formátumú anyagokká tudjuk alakítani. 
Jelenleg gyakorlatilag nem léteznek eszközök az 
e-könyv formátumok PDF vagy OpenDocument for- 
mátumba (az OpenOffice.org által használt új OASIS 
szabvány) történő kimentésére; szerencsére ez nem 
jelenti azt, hogy az átalakítás ne volna megoldható. 
Ha egyszer a szöveg már ASCII vagy HTML formátumot 
kapott, szövegböngésző -— például w3m - vagy egyéb 
program -— mint a html2ps — segítségével már könnyedén 
átalakítható egyszerű szöveggé vagy PDF fájllá. Ha ezt 
az utat választjuk az átalakításra, akkor azt akár már 
ma is elvégezhetjük, hiszen utóbbi nyílt formátum, 
ahogy 20 év múlva is az lesz. 


PalmDoc 

PalmOS alatt az eredeti és legelterjedtebb e-könyv 
formátum a PalmDoc, más néven AportisDoc vagy 
egyszerűen Doc; nem keverendő össze a Microsoft 
Word hasonló nevű, .doc formátumával. A Doc formátu- 
mú fájlok a .pdb (Palm Database, Palm adatbázis) vagy 
a .prc (Palm Resource Code, Palm erőforráskód) kiterjesz- 
tésről ismerhetők fel, mindkettő lényegében összefűzött 
rekordokat tartalmazó PalmPilot adatbázist rejt. 
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CHAPTER XII 


OF THE STRANGE ADVENTURE WHICH BEFELL THE VALIANT 
DON OUIXOTE WITH THE BOLD KNIGHT OF THE MIRRORS 


The night succeeding the day of the encounter with Death, Don Ouixote and 
his sguire passed under some tall shady trees, and Don Ouixote at Sanchoss 
persuasion ate a little from the store carried by Dapplec, and over their supper 
Sancho said to his master, "Senor, what a fool I should have looked if I had 
chosen for my reward the spoils of the first adventure your worship achieved, 
instead of the foals of the three mares, After all, "a sparrow ín the hand is 
better than a vulture on the wing." 


"At the same time, Sancho," replied Don Ouixote, "if thou hadst let me 
attack them as I wanted, at the very least the emperors gold crown and 
Cupids painted wings would have fallen to thce as spoils, for I should have 
taken them by force and given them into thy hands," 





"The sceptres and crowns of those play-actor emperors," said Sancho, "were 





1. ábra PalmDoc fájl böngészőben jobban megjeleníthető 
HTML formátumúra alakítva 


A szabványból később több változat is kialakult, többek 
közt az alapszintű formátumot HTML címkékkel bővítő 
MobiPocket. 

Minden Palm e-könyv három részből áll: a fejrészból, 

a szövegrekordok sorozatából és a könyvjelzők soro- 
zatából. Alapesetben a fejrész 16 bájtos, bizonyos 
Doc-olvasók ezt futási időben, egyedi adatok tárolása 
céljából kibővítik. Alapesetben a fejrész adja meg többek 
közt a tömörítetlen szöveg teljes hosszát, a pillanatnyi- 
lag megjelenített rész pozícióját, illetve tartalmaz egy 

két bájtos, előjel nélküli egész számokból álló tömböt, 
mely az egyes szövegrekordok tömörítetlen méretét jelzi. 
A rekordok maximális mérete jellemzően 4096 bájt, 

és a rekordok tömörítése egyenként történik. 

A könyvjelző rekordok egy 16 bájtos névből és egy 

4 bájtos, a szöveg kezdetétől számított eltolásból állnak. 
Mivel a könyvjelzők elhagyhatók, sok Doc e-könyv 
nem is tartalmazza őket, a Doc-olvasók pedig sokszor 











1. kódrészlet Egyszerű Perl parancsfájl 
a Pyrite által kimentett szöveg 
HTML-lé alakítására 


$! /usr/bin/per1 

undef $/; 

STENNSES: 

$TEXT -- s/inm/cp:/gm; 
print ccEND HTML; 
chtml3cbodyz 

$TEXT 

c/bodyzsc/htmls 

END HTML 


másféle, vagyis nem hordozható módszereket is támo- 
gatnak megadásukra. Az egyes olvasóprogramok saját 
kiterjesztései kategória, változatszám, illetve e-könyvek 
közötti hivatkozások megadására is alkalmasak lehetnek. 
Utóbbi adatok szinte mindig a .pdb vagy .rc fájlon kívül 
tárolódnak, vagyis ne várjuk megőrzésüket, amikor 
e-könyveinket átalakítjuk. 

A Pyrite Publisher, korábbi nevén Doc Toolkit egy 
tartalomátalakító eszközöket magába foglaló készlet 
Palm rendszerekhez. Jelenleg csak néhány szövegformá- 
tum átalakítására van lehetőség, ám szolgáltatásait 
Python beépülő modulok segítségével bővíteni is lehet. 
A Pyrite Publisher alkalmas az átalakítandó dokumen- 
tumok közvetlenül, webről történő letöltésére és a letöl- 
tött könyvjelzők közvetlenül a kimeneti adatbázisba 
való beillesztésére is. A csomag használatához 2.1-es 
vagy újabb Python szükséges, futtatása pedig parancs- 
sorból vagy a wxWindows alapú grafikus felülettel 
történik. A program Linux és Windows alá érhető el, 
forrás és bináris fájl formájában egyaránt. Ha az utóbbit 
választjuk, akkor ne feledjük el, hogy a legtöbb előre 
lefordított program a /usr könyvtárban keresi a Pythont. 
A linuxos változat az átalakított fájlokat a JPilot vagy 

a pilot-link segítségével azonnal át tudja másolni zseb- 
titkárra is. 

A Pyrite telepítése és futtatása Fedora Core 2 alatt problé- 
mátlan volt. Az egyéb, később említendő parancssori átala- 
kítókkal ellentétben a Pyrite csak ASCII formátumba tud 
menteni, HTML-be nem. A futtatható fájl neve pyrpub. 

A .pdb fájlok átalakításához a következő parancsformátu- 
mot kell használni: 


pyrpub -P Textoutput -o don guixote.txt N 
Don. Ouixote.pdb 


Ha csak gyorsan tárgymutatót akarunk készíteni egy digitá- 
lis könyvtárról, akkor a Pyrite-on kívül másra nem is lesz 
szükségünk. Ugyanakkor a kimenetet nem nehéz tovább 
formázni, amivel böngészőben is könnyebben olvashatóvá 
válik. Az alábbi, Perlben készült kódrészlet ugyan csúnya, 
ám tökéletesen megfelel a Don Owixote HTML változatának 
előállítására. (1. kódrészlet) 
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A parancsfájl betölti a teljes korábban a Publisher 
segítségével létrehozott ASCII szöveget, és minden 
alkalommal, amikor új sor karaktert talál, a helyére 

a bekezdés HTML címkéjét illeszti. Az alapszintű 

HTML formázású eredményt a szabványos kimenetre 
írja ki. Ha meg akarjuk változtatni az igazítást, a betű- 
típust vagy a színeket, akkor csak annyit kell tennünk, 
hogy a megfelelő stíluslapot beillesztjük a chtml5cbodyz 
sor mögé. 

A várhatóan 2005 tavaszán megjelenő OpenOffice.org 2.0 
.pdb formátumban is képes lesz menteni a szövegeket. 

Ha olvasni is képes lesz az ilyen fájlokat, akkor tömeges 
átalakítási szolgáltatásával (Files AutoPilot:Document 
Converter) az egész átalakítási kérdés egy csapásra elegáns 
megoldást nyer. Kipróbáltam a szolgáltatást az 1.9.m65-ös 
előzetes kiadásban, de egyelőre csak egy általános ki/bevi- 
teli hibára utaló üzenetet sikerült kapnom. Remélhetőleg 
a későbbi változatokban már tökéletesen fog működni 

ez a szolgáltatás is. 


A P5 Perl csomag 

A Pyrite Publishert elsősorban normál HTML vagy 
szöveges fájlok Palm gépeken olvasható formátumra 
alakítására készítették, a több lehetőség inkább mel- 
lékhatásként fogható fel. A fent ismertetett eljárás 
csak nehézkesen alkalmazható, ha például nagy 
mennyiségű, egyedi HTML címkéket, hiperhivat- 
kozásokat és metaadatokat tartalmazó palmos e-köny- 
vet kell átalakítani. Ilyenkor a legjobb megoldás egy 
Perl parancsfájl alkalmazása, igénybe véve a nyelv 
szabványos XML vagy HTML és P5-Palm moduljait. 
A modulokat a Comprehensive Perl Archive Network 
(lásd az internetes forrásokat) webhelyről lehet elérni. 
A P5-Palm modulkészletben található osztályok segít- 
ségével a PalmOs alapú készülékek által használt .pdb 
és .prc adatbázisfájlok olvasása, feldolgozása és írása 
egyaránt megoldható. 


A Rocket Ebook és a MobiPocket 

A RocketBook e-könyvek több érdekes jellegzetesség- 
gel is rendelkeznek, például támogatják a tömörített 
HTML fájlokat, valamint a bekezdések formázásait és 

a hivatkozási nevek pozícióit összegző indexeket. Ezek- 
ről és az .rb fájlok pontos felépítéséről az internetes 
források között található, az RB formátumot ismertető 
oldalon lehet bővebben olvasni. A Rocket Ebook és 

a Mobipocket fájlokat szétbontani az Rbmake nevű 
parancssori eszközkészlettel lehet. A készlet honlapján 
forráskódot, bináris csomagokat, levelezési listát és hiba- 
jelentések elküldésére alkalmas címet egyaránt találunk. 
Az rbmake használatához szükség van a libxml2 2.3.1-es 
vagy újabb változatára, a pcre (Perl-Compatible Regular 
Expressions) könyvtárra, illetve a tömörítések kezelése 
miatt a zlib-re. A forrásból történő fordítás elvégzéséhez 
— legalábbis Fedora Core 2 alatt — külön telepíteni kell 

a pcre-devel csomagot is. 


Az Rhmake könyvtár 
Az Rbmake egyik pozitívuma modulárisan összeállított 
forráskódja. Ha úgy akarjuk, egy teljes objektumorientált 
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2. ábra Az Rbmake a RocketBook fájlok összes 
összetevőjét kibontja, ide értve a szöveget 
és a képeket is 


2. kódrészlet Az OPF egy XML alapú 
formátum könyvek 
jellemzőinek leírására 


cdc:TitlezsA Midsummer-Night"s Dreamc/dc:Titlez 
cdc:Creator role-"aut" 
file-as-"Shakespeare, william, 1564-161675 
william Shakespeare, 1564-1616 
c/dc:Creators 
cdc:Descriptionsfiction, poetryc/dc:Descriptions 


C könyvtárat le tudunk fordítani, függetlenül a cso- 

mag egyéb részeitől, így bármilyen más programból is 
kezelni tudjuk az .rb fájlokat. Ezzel a módszerrel saját, 
akár minden részletében testreszabott Rocket Ebook 
átalakítót is tudunk írni, esetleg az összes e-könyvünkről 
jegyzéket készíthetünk egy adatbázisba; minden esetben 
csak arra a kódrészre van szükségünk, amely az .rb for- 
mátum tényleges írásáért és olvasásáért felelős, vagyis 
az RbFile osztályra. Ez a kódrész megnyitja a fájlt, 
visszaadja a könyvet alkotó szakaszok listáját, majd fu- 
tás közben csak a főprogram által ténylegesen igényelt 
részeket bontja ki. Ha éppen arra van szükségünk, 

a könyvtár keresési és cserélési eljárásokkal is rendelke- 
zik, ezeket a Perl-ben megszokott reguláris kifejezésekkel 
tudjuk használni. 

Az Rbmake eszközöknek minden korszerű GNU/Linux 
terjesztésen gyorsan és gondok nélkül le kell fordulni- 
uk. A forrás .tar állományban részletes HTML leírást 

is találunk. A HTML fájlok előállítására alkalmas biná- 
ris fájl az rbburst. A program az eredeti .rb konténerben 
lévő összetevők - szöveg, képek és leíró adatok — 
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Arhens. The palsce of THESEUS, 
Eper THESEUS, HIPPOLYTA, PHILOSTRATE. and Ancodants 


THESEUS 


Now, fair Hippolyta, out nuptial hour 
Denes on apace; four happy days being ím 
Another moon. but, 0. methinks. hos ak 
This old moon wancs! she lingers my despes. 
Like 10 a gep dame or a dowiget 

Long withering 00£ a yovag man revenve. 


2. ábra A Convert Lit jól olvasható HTML 
fájlt állít elő, hiperhivatkozásokból 
álló tartalomjegyzékkel 


mindegyikét kibontja. A 2. ábrán két Mozilla ablakban 
látható, hogy H. G. Wells The Invisible Man című 
könyvén az rbburst-öt futtatva milyen fedlapot 

és tartalomjegyzéket kapunk. 


Microsoft Reader 

A Microsoft Reader fájlokat a .lit kiterjesztésről 
ismerhetjük fel. Számos a hagyományos könyvekre 
jellemző tulajdonságuk van, mint például oldalszámok, 
kiemelések és jegyzetek. A kulcsszó alapú keresést és 

a hiperhivatkozásokat is támogatják, ám egyetlen olva- 
sóprogramhoz kötődnek. 

Az ilyen fájlok átalakítására szolgáló eszköz neve spár- 
tai egyszerűséggel Convert Lit. A programot a -help 
kapcsolóval futtatva — hűen a unixos hagyományokhoz — 
az összes parancssori kapcsolót megtekinthetjük. 

A program háromféle üzemmódot ismer: robbantás 
(explosion), lefelé átalakítás (downconversion) és dedi- 
kálás/beleírás (inscribing). Meglévő .lit fájlt OEBPS- 
megfelelő csomagba a robbantás móddal tudunk átala- 
kítani. Az OEBPS-ről (Open eBook Publication Structure) 
később még lesz szó. 

A 3. ábra Shakespeare A Midsummer"s Night Dream 
című művének a Convert Lit programmal robbantott 
változatát szemlélteti. A lefelé átalakítás ezzel ellenté- 
tes eljárás, általa Microsoft Reader-megfelelő eszközö- 
kön használható .lit fájlt kapunk. A beírásnál a lefelé 
átalakítás közben felhasználó által megadott feliratot 
csatolunk a .lit fájlhoz. A pontos szintaxist illetően 

a program honlapján találunk részletes tájékoztatást 
(lásd a forrásokat). 

Már volt róla szó, hogy a Convert Lit egy különbö- 

ző fájlokból álló OEBPS csomagot állít elő. A fenti 
példánál a teljes fájllista a következő: Contents.htm, 
copyright.html, —covO024.htm, cover.jpg, 
MidSummerNightDream.opf, MobMids.html, PCcover.jpg, 








PCthumb.jpg, stylesheet.css és thumb.jpg. A HTML, 

a CSS és a JPG fájlok különösebb meglepetést nem 
jelentenek, de vajon mi célt szolgál az .opf fájl? 

Ez egy XML konténer, ez írja le az eredeti könyvben 
található metaadatok egyes részeinek szerkezetét. 

Az OPF kiterjesztés az electronic book package formatra, 
az elektronikus könyv csomag formátumra 

utal. Az OPF az e-könyv egyéb részeire mutató hivat- 
kozásokat is tartalmaz, illetve magába foglalja jellem- 
zőik leírását is. Szerepét könnyebben átláthatjuk egy 
példán keresztül, ezért a 2. kódrészletbe bemásoltam 

a MidSummerNightDream.opf egy kisebb részét. 

A gyakorlatban mindebből az fakad, hogy a Convert Lit 
akkor is jól használható lehet, ha teljes gyűjteményünket 
zárt, gyártófüggő formátumban akarjuk hagyni. Ekkor 
elég futtatnunk a programot az összes .lit formátumú 
e-könyvünkön, majd az .opf fájlok kivételével törölnünk 
mindent. Ezt követően egy rövidke parancsfájllal vagy 
akár egy nagyobb tudású XML feldolgozó programmal 
végig tudunk menni ezeken, és az általunk kívánt adatbá- 
zisba tudjuk másolni a tárgymutatót. 

A Comvert Lit a digitális jogkezelő (digital rights 
management, DRM) tészeket is eltávolítja az e-könyvek- 
ből, legalábbis ami a régebbi, DRM1 változatot illeti. 

Ha Microsoft Reader e-könyveket gyűjtünk, valószínűleg 
Microsoft Windows operációs rendszerrel és a Microsoft 
Reader egy jogtiszta példányával is rendelkezünk. 

A Convert Lit weboldala szerint a Convert Litet Windows 
alatt lefordítva, a Windows DRM segítségével az újabb 
DRM5-öt alkalmazó e-könyveket is át tudjuk alakítani 
DRM1I-essé. 


Tömeges átalakítás 

Eddig inkább parancssori átalakításokról volt szó. Aki 
viszont nagyobb, többféle formátumból összeálló e-könyv- 
gyűjteménnyel rendelkezik, az egyetlen héjparancsfájllal 
egyszerre is elvégezheti ezek átalakítását. Mint már láttuk, 
ha a szöveg átkerül ASCII vagy HTML formátumba, 

a határ a csillagos ég. A ciklust egy-két sorral bővítve 

a tárgymutató elkészítése a glimpse vagy a ht: :dig 
használatával is megoldható; akár mindent beírhatunk 
egyetlen PostScript könyvbe és így tovább. 


OEBPS 


Jelenleg még fejlesztés alatt álló megoldás e-könyvek 

— legalábbis a közeljövőben beszerezhető példányok — 
nyílt formátumba alakítására. Pontos neve Open eBook 
Publication Structure (nyílt e-könyv kiadási szerkezet, 
OEBPS). Célja egy XML-alapú, a meglévő nyílt szab- 
ványokra épülő szabálygyűjtemény összeállítása többfé- 
le e-könyv rendszeren történő tartalomszolgáltatáshoz. 
Az OEBPS-t, mely immár 1.2-es változatban érhető el, 
az Open eBook Forum tartja karban. A csoportban több 
mint 85 szervezet található meg, hardver- és szoftver- 
gyártók, kiadók, szerzők és az elektronikus kiadvány- 
ok piacán érdekelt felhasználók egyaránt. Az OEBPS 
önmagában, közvetlenül semmilyen digitális jogkezelést 
nem szolgál. Az OeBF Rights and Rules Working Group 
(jogok és szabályok munkacsoport) azonban szorgalma- 
san tanulmányozza a vonatkozó kérdéseket, munkájának 
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célja ,egységes, kölcsönösen támogatott előírásgyűjte- 
mény összeállítása az elektronikus kiadói közösség 
számára". Még meglátjuk, mi sül ki belőle. 

Bármi is történjék, az OEBPS háttereként szolgáló 

nyílt szabványok szilárd alapokra épülnek. Az XML, 

az Unicode és az XHTML mellett a CSS1 és a CSS2 bizo- 
nyos részei is szerepelnek benne. Az Unicode kódolások 
családja, alkalmazásával több tízezer karaktert is félreérté- 
sek és keveredések nélkül lehet kezelni. Az XHTML 

a HTML 4 új, XML alapú megtestesülése. Az OEBPS rö- 
viden talán úgy jellemezhető, mint az XHTML e-könyvek 
kezelésére testreszabott változata — olyasvalami, ami ak- 
kor is fennmarad, ha a támogatását adó vállalatok néme- 
lyike esetleg el is tűnik az üzleti élet porondjáról. A képek 
PNG vagy JPEG formátumúak lehetnek. A metaadatok 
(szerző, cím, ISBN stb.) kezelése a Dublin Core szótáron 
keresztül fog történni. 

Az OEBPS tehát alkalmas arra, hogy az összes e-köny- 
vünket megőrizzük, és biztosítsuk időtállóságukat, még 
akkor is, ha némelyik hardver- vagy szoftvergyártó neve 
néhány év múlva homályos emlékké válik. Sajnos az 

ilyen , nyílt" e-könyvekre alkalmazott DRM megoldások 
egy-egy gyártóhoz köthetnek bennünket. Amíg az OEBPS 
e-könyveket DRM nélkül tudjuk beszerezni, addig az 
OEBPS a legjobb megoldás annak biztosítására, hogy 
gyűjteményünk még akkor is használható maradjon, 

ha az ezen a piacon érdekelt cégek akár mindegyike 

a süllyesztőbe kerül. 
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Marco Fioretti hardver-rendszermérnök, 

a szabad szoftverekkel mint EDA alaprend- 
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létrehozására irányuló RULE Project 
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Készítsünk Impress és PowerPoint bemutatót 
LaTeX és Perl segítségével 


Aki valamiért kénytelen védett formátumokat használni, a nyílt forráskód annak 


is megkönnyítheti a dolgát. 


ezdjük az elején. 
Második könyvem, melyet Dr. Michael 


Moorhouse-al közösen készítettünk, végre elké- 
szült. Hat hónap plusz időt töltöttem vele, ami egyben azt 
is jelentette, hogy hat hónap késésben voltam. Az összes 
időt szedéssel, átolvasással, írással és Michael Microsoft 
Word állományainak LaTeX formátumúra alakításával töl- 
töttem, elolvasva majd újra elolvasva mindent. Végül mind- 
et még egyszer átnéztem. Amikor végre minden elkészült, 
teljesen kimerültem. Nem sokkal ez után megkaptam a bo- 
rító végleges mintáját. És akkor kiderült, hogy a hátlapon 
azt ígérjük, hogy a weblapon a szöveggel együtt használha- 
tó Microsoft PowerPoint bemutatók jelennek majd meg. 

A borító megváltoztatásához már túlságosan késő volt, kö- 
vetkezésképpen valahogy meg kellett csinálni a bemutató- 
kat. Úgy tűnik elfelejtettem, hogy ebben egyeztünk meg 

a projekt indításakor, több mint 18 hónappal korábban. 


A PowerPoint , szabvány" 

Nyolc hónappal ezelőtt, akadémia berkekben a bemutatók 
de facto szabvány formátuma a PowerPoint volt. Manapság 
már a PDF is népszerű. Mint oly sokan a Linux közösség- 
ben, már régebben átálltam az OpenOffice.org-ra és el- 
hagytam a PowerPoint környeztet. A könyvben 20 fejezet 
szerepelt, úgy becsültem, hogy körülbelül 20 napba telik 
elkészíteni a diákat. Ráadásul mindezt a PowerPointtal 
megcsinálni nem igazán volt ínyemre. Természetesen dol- 
gozhattam volna az OpenOffice.org Impress-ében, majd azt 
exportálhattam volna PowerPointba, de ez az ötlet sem tet- 
szett különösebben. Az alapvető probléma az volt, hogy 

jól tudtam, minden adat megvolt LaTeX állományokban, 

és ha arra gondoltam, hogy ezeket mind újra létre kell hoz- 
ni egy fóliakészítő alkalmazásban csak még kimerültebbnek 
éreztem magam. Ha valahogy ki tudnám találni, hogyan 
lehet programozottan kiszedni az adatokat a LaTeX állomá- 
nyaimból és beletenni a PowerPoint diákba, az jelentősen 
leegyszerűsítené a dolgokat. 


Munka a bemutató fájlfornátumokkal 
A Google keresés nem hozott eredményt. Talán nem is 
meglepő, hogy a PowerPoint fájlformátum részleteihez igen 
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nehéz ráakadni. Találtam egy Microsoft Windows Help for- 
mátumú állományt amely a Microsoft Office dokumentu- 
mok XML szabványát ismertette. Ebbe a formátumba lehet 
a PowerPoint dokumentumokat exportálni. Sajnos igen mé- 
retes és bonyolult írás volt. Miután láttam, hogy a Goo0gle-lel 
nem sokra megyek, átnyergeltem a Comprehensive Perl 
Archive Network (CPAN) hálózatára. A Perl, a választott 
programozási nyelvem, szinte minden fájlformátumra és 
számítási platformra felkészült. Ha valaki korábban már 
játszadozott kicsit a Perl és PowerPoint párossal, munkájára 
esetleg ráakadhatok a CPAN-on. Sajnos ez a keresés is ered- 
ménytelen maradt. 

És akkor rájöttem a megoldásra: ha a nyílt és széles körű- 
en dokumentált OpenOffice.org Impress dokumentumfor- 
mátummal tudnék dolgozni, utolsó lépésként az Impress 
diákat kimenthetném PowerPoint formátumba. 

Az OpenOffice.org weblap gyors átolvasása után hamarosan 
meg is találtam a OpenOffice.org fájlformátumainak XML 
leírását. A szabvány a maga 600 oldalával, súlyosabb mint 

a saját könyvem! 

Az XML dokumentum szépen meg van írva, de egy 

kicsit nehéz olvasmány. Visszakanyarodtam hát 

a CPAN-ra, hátha dolgozott már valamelyik programozó 
az OpenOffice.org formátumaival, és volt olyan nagylelkű, 
hogy feltöltötte munkáját a CPAN-ra. Ezúttal nem kellett 
csalódnom. Jean-Marie Gouarne a Genicorptól nemrégiben 
adta közre az OpenOffice::OODoc modult, amely a Perl 
csatoló felületet biztosít az OpenOffice.org formátumához. 
Egy már létező dokumentum esetében az 
OpenOffice::OODoc modullal módosíthatjuk a tartalmat, 
igény szerint hozzáadhatunk, törölhetünk és frissíthetünk 
a lemezes állományban. 


A diakészítő terve 

Egy egyszerű Perl szűrővel kezdtem amely LaTeX állomá- 
nyokat fogad bemenetként és dia adatokat készít kimenet- 
ként saját szöveges formátumban. A szöveges állomány 
létrehozásával biztosítani tudtam, hogy bármilyen szöveg- 
szerkesztővel könnyedén módosítani tudom a szűrő kime- 
netét, illetve szükség esetén finomhangolhatom a szöve- 
ges kimenetet. Amikor elértem a kívánt eredményt, egy 











másik, szintén Perlben készült szűrő a szöveges állo- 
mányból elkészíti az Impress bemutatót. Az Impress bemu- 
tatót aztán meg lehet nyitni Impress-ben és exportálni 
PowerPoint vagy PDF formátumban. 


Dia tervek 

A bemutatómat tudatosan próbáltam a lehető legegysze- 
rűbb alakban elkészíteni, ezért úgy döntöttem csak három 
diatípust használok. A cím dia tartalmazza a fejezet címét 

a bemutató állomány elején. A bemutatóban a title slide 
(cím dia) kettős szerepet tölt majd be, ez tartalmazza majd 
a bemutatóba illesztett képeket is, azaz képenként külön 
title slide-ot készítünk. A bullet slide (pont dia) tar- 
talmazza a szakaszok címeit a dia fejlécében valamint az 
alcímeket a pontokban. Végül, a sourcecode slide típusú, 
rögzített karakterhosszúságú, betű szerinti diákat haszná- 
lom fel a programforrások megjelenítéséhez. 

A három diás bemutatót kézzel készítettem el Impress-ben és 
blank.sxi-nek néven mentettem el. Az elkészített három dia 
az előző bekezdésben bemutatott három diatípusnak felelt 
meg. Úgy terveztem, hogy a fejezetek programozott bemu- 
tatókészítése során ezeket fogom majd másolni. A másolás 
segítségével biztosíthatom a bemutatóm egységes külalakját. 


A szöveges tartalom kigyűjtését végző szűrő 

A getcontent olyan stílusú héjprogram, amilyeneket igen 
gyakran készítenek a Perl programozók, felhasználják, 
majd eldobják őket. (A hálózati források közt megtaláljuk 
a cikkben említett programok forrását) Soronként olvasva 
végiglépked a szabványos bemeneten, és mintakereséssel 
próbálja meg felderíteni a lényeges sorokat. Ha a sor meg- 
felel a keresésnek, elkészíti a megfelelő kimenetet. 

A getcontent működésének bemutatására álljon itt példa- 
ként a LaTeX állomány fejezetcímeit kezelő kód: 


if ( Mchaptertű( "9 V/ ) 

í 
print "CHAPTERTITLE: $14n"; 
next; 


A LaTeX fejezet makróját egyszerű szabályos kifejezés 
keresi ki; Ha volt egyezés, a fejezet címét kigyűjtjük és elké- 
szítjük a kimenetet. A next hívás rövidre zárja a kört, így 
ha találtunk valamit, a szabványos bemenetről a következő 
sort olvassuk be. Ezáltal a következő LaTeX részlet: 


vchapterfworking with Regular Expressionsz 

a következő szöveges tartalomra cserélődik le: 
CHAPTERTITLE: Working with Regular Expressions 
Azaz a LaTeX jelrendszerét eltávolítottuk, és egy sokkal 
egyszerűbb jelöléssel cseréljük le. A alfejezet és szakasz- 
címeket jelölő LaTeX formátumot ugyanilyen módszerrel 


kezeljük. A kód a következőképpen néz ki: 


if ( /MsectionfC."9U/ ) 
í 
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print "BULLETTITLE: $14n"; 


next; 

s 

if ( /M subsectiontf(."JU/ ) 

í 
print "BULLETCONTENT: $14n"; 
next; 

3 


A forráskódlistákkal sem sokkal nehezebb boldogulni, 

igaz itt figyelnünk kell rá, hol kezdődik és végződik a nyers 
szöveg bevitele. A következő kódrészlet kezeli a LaTeX 
rverbatim" blokkját: 


if ( Mbeginyíverbatimu/ ) 


í 
print "STARTCODEW"; 
$in verbatim - TRUE; 
next; 

3 


A verbatim blokkból kilépést pedig a következő kóddal 
keressük: 


if ( $in verbatim ) 


í 
if ( /Mendtíverbatimu / ) 
í 
print "STOPCODEM"; 
$in verbatim - FALSE; 
s 
else 
í 
print; 
s 
next; 
J 


A $in verbatim nevű egyszerű bool típusú változó segít- 
ségével vizsgáljuk, hogy a parancsfájlunk még a verbatim 
blokk belsejében van-e. Hasonló kód kezeli a könyvben 
megjelenő tételeket a képeket, azok feliratai és egyéb érde- 
kes dolgokat pedig néhány feltétles blokk kezeli. vegyük 
például a következő LaTeX leírást: 


VvchapteríTrhe Basics3 
VtextitíGetting started with Perl.3 
VsectioníLet"s Get Started!3 
There is no substitute for practical experience 
5 when first 
learning how to program. So, here is the first 
5 Perl program 
Vindexíwelcomedytextttíwelcomel, and the first 
5 program, called 
Vtextttíwel come): 
tbeginíverbatimjt 

print "Welcome to the world of Perl! Mn"; 
Vendíverbatimt 
Mnoindent when executed by Mtextttíper1l3 
tVfootnotefWe will learn how to do this is in 
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just a moment.t, this small program displays 
the following, perhaps rather not unexpected, 
message on screen: 
Mbeginíverbatimt 

welcome to the world of Perl! 
Vendíverbatim? 


A getcontent parancsfájlja a fenti LaTeX állományból 
a következő szöveges állományt készíti: 


CHAPTERTITLE: The Basics 
CHAPTERCONTENT: Getting started with Perl. 
BULLETTITLE: Let"s Get Started! 
STARTCODE 
print "Welcome to the world of Perl! in"; 
STOPCODE 
STARTCODE 
welcome to the world of Perl! 
STOPCODE 


Figyeljük meg hogy valamennyi LaTeX jelölés eltűnt, 

és helyére egy egyszerű jelölésrendszer került, amelyet 
majd a diák létrehozására használhatunk fel. Feltételezve, 
hogy a LaTeX részlet a chapter3 . tex nevű állományban 
kapott helyet, a getcontent parancsfájlt elindítva, az átala- 
kítás eredményét átirányítjuk a megfelelően elnevezett 
célállományba: 


per] getcontent chapter3.tex 3: chapter3.input 


A chapter3. input állományba így a szöveges tartalom 
kerül, amit aztán tetszőleges szövegszerkesztővel finom- 
hangolhatunk a diák létrehozása előtt. 


Az Impress bemutató készítő szűrő 

A diák létrehozását az Inpress dokumentumban több té- 
nyező is nehezítette. Először is az OpenOffice::OODoc mo- 
dullal nem hozhatunk létre új OpenOffice.org állományt, az 
ugyanis csak a már létező állományokat tudja módosítani. 
Továbbá a modult elsősorban az OpenOffice.org Writer állo- 
mányok (tehát szövegszerkesztő fájlok és nem Impress be- 
mutatók) szerkesztésére készítették. Példaként álljon itt 

egy rövid, appendpara nevű program, amely rövid szöveget 
fűz a Writer dokumentumunkhoz: 


$! /usr/bin/per1l -w 
use strict; 
use Openoffice: :O00ODOC; 
my $document - ooDocument( file -5 "blank.sxw"? ); 
$document-sappendParagraph 
( 
text -5 "Some new text", 
style -—s "Text body" 
); 


$document-ssave; 


A rövid program az Openoffice : : 0ODoc modul segítségével 
készít dokumentum objektumot egy már meglévő Writer 
állományból. A program ezután az appendParagraph metó- 
dus meghívásával beszúr némi szöveget majd meghívja 
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a save metódust és a lemezre menti a változtatásokat. 

Az appendParagraph metóduson felül az 

openoffice: : ooODoc modulban találunk egy insertElement 
nevű metódust is, amellyel egy adott típusú lapot szúrha- 
tunk a dokumentumba. A lap egy már meglévő lap másola- 
ta vagy tényleges nyers XML lehet. 

Alig jutottam el a 6. oldalig a több mint 600 oldalas 
OpenOffice.org XML fájlformátum leírásban, máris megta- 
láltam, hogy az Impress a //draw: page XML típust hasz- 
nálja a bemutatók diáinak megjelenítésére. Sajnos az 
Openoffice: : OODoc modul ezzel az objektumtípussal köz- 
vetlenül nem tudott dolgozni, úgyhogy valamilyen más 
módszert kellett kieszelnem az adatok kezeléséhez. 
Egészen pontosan a blank.sxi dokumentumban lévő lapo- 
kat szerettem volna kiemelni és szükség szerint másolni 
az oldalait, miközben a dia tartalmát a getcontent parancs- 
fájl által gyűjtött tartalommal helyettesítem. Ehhez persze 
egy kicsit jobban meg kellett ismernem az Impress XML 
formátumát. 

Két választássom volt: tovább olvasom a 600-- oldalas 
szabványdokumentációt, vagy belenézek egy létező állo- 
mányba hátha eleget megtudok a feladat kivitelezéséhez. 
Az utóbbit választottam. Emlékezve egy korábbi Linux 
Journal cikkre mely szerint az OpenOffice.org több részből 
álló állományait a népszerű ZIP algoritmussal tömöríti, 
készítettem egy ideiglenes könyvtárat és kitömörítettem 

a blank.sxi állományt: 


mkdir unzipped 
cd unzipped 
unzip ../blank.sxi 


Ezáltal kaptam néhány fájlt és könyvtárat: 


content.xm! 
META-INF 
meta.xm!i 
mimetype 
settings.xm! 
styles.xm! 


a legérdekesebb a content.xml állomány, hiszen ez tartal- 
mazza a dokumentumot alkotó tényleges szöveget. képer- 
nyőn vagy egy szövegszerkesztőben nézve rengeteg nehe- 
zen értelmezhető XML kódot látunk. Azért, hogy a részek 
lehető legkisebbek legyenek, az XML formázására egyálta- 
lán nem fordítottak semmilyen figyelmet, a zippelt állo- 
mány egyik részében sem. Az XML általában tagolás és 
szóközök nélküli szövegfolyamként kerül mentésre. Mielőtt 
értelmezhettem volna, valamilyen olvasható formában 
kellett kinyomtatnom ezt az XML-t. Pillanatnyi ihlettől 
vezérelve, átléptem parancssorba és begépeltem az xm1 
szót két tabbal kísérve. A képernyőn megjelentek az xm1-el 
kezdődő előre telepített szóközök: 


xm12-config xm1l-config xmilint 

xmilto xml2man xml-i18n-toolize 
xmlproc parse xmiwf xmi2pot 

xmlif xmiproc val xmlcatalog 
xmlizer xmiltex 








Az xmiTint egyből felkeltette az érdeklődésemet. A kézi- 
könyv oldalán hamar rábukkantam a --format kapcsolóra, 
amely - ahogy azt biztosan kitalálták — formázza az eszköz- 
nek átadott XML adatokat. Következésképpen az xmilint 
--format content.xmi] paranccsal olyan kimenetet kaptam 
amit aztán a less-be csövezve már nehézségek nélkül el le- 
hetett olvasni. Alább bemutatjuk a content.xml olvasható 
formában kinyomtatott rövidített részletét, ahol a blank.sxi 
Impress dokumentum title slide XML részletét láthatjuk: 


cdraw:page draw:name-"pageli" draw:style- ... 
cdraw:text-box presentation:style-name- ... 
ctext:p text:style-name-—-"P1l": 
ctext:Span text:style-name-"T175 
chapterritleslide 
€x/text:span: 
c/text:p: 
€/draw: text-boxsz 
cdraw:text-box presentation:style-name- ... 
ctext:p text:Style-name—-"Pp37"5 
ctext:Span text:style-name-"T275 
chapterritleslideTrext 
€x/text:Sspanz 
c£/text:p: 
€/draw: text-boxz 
cpresentation:notesz 
cdraw:page-thumbnail draw:style-name— ... 
cdraw:text-box presentation:style-name ... 
c/presentation:notesz 
c/draw:pagez 


Figyeljük meg a chapterrTitleslide és 

a ChapterrTitlesliderext tartalmat, amelyeket a blank.sxi 
létrehozásakor gépeltem be az Impress-be. Ha az 
insertElement metódus segítségével e részlet alapján be 
tudnék vinni nyers XML adatokat, miközben az üres tartal- 
mat a saját szöveges adataimmal helyettesítem, lényegében 
már készen is volnék. 

A példa kedvéért gondoljuk végig mi is történik, amikor 

a bemutató címét és alcímét feldolgozza a produce slides 
rutin. Az insertElement a következő formában hívódik 
meg, létrehozva a az új diát: 


$presentation-sinsertElement( "//draw:page" , 
$last slider-, 
title slide( $title title, $title content ), 
position —5 "after? ); 


A title slide alprogram nyers XML adatot ad vissza, 
amit a dokumentumba szúrhatunk. 

Ha a getcontent által készített szöveges tartalommal 
egyező formátumú bemenetei állományt használunk, 

a produce slides parancsfájl lemásolja a blank.sxi Impress 
állományt majd tetszőleges számú diával tölti fel, így prog- 
ramozottan hozza létre a bemutatót. A parancsfájl szerkeze- 
tében nem különbözik sokban a getcontent-től mindössze 
annyi a különlegessége, hogy a blank.sxi állományban 
tárolt, három különféle diatípushoz tartozó nyers XML 
adatot átemeli. Az előadás elkészítéséhez a következő alak- 
ban hívjuk meg a produce slides programot: 
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per] produce slides 3 chapter3.input 


Eredményképpen egy új Impress dokumentumot 
kapunk, amely chapter3.sxi néven jelenik meg a me- 
revlemezünkön. 

Miután létrehoztam az Impress állományt, a grafikus 
képek helyfoglaló elemeit le kellett cserélnem a tényle- 
ges képekre. A getcontent parancsfájl azonban csak 

a képek neveit bontotta ki, és nem magukat a képeket. 

A képek importálása Impress alá nem lenne túl nehéz 
feladat, eltekintve attól, hogy az általam birtokolt eredeti 
állományok meglehetősen gyenge minőségűek voltak 
azokhoz képest amelyek végül a könyvbe kerültek. 

A könyvbe kerülő képeket jelentősen feljavította a kiadó 
végső szedőfázisa. Nekem pedig természetesen nem vol- 
tak meg ezek az állományok. 

Aztán eszembe jutott, hogy a kiadó elküldte nekem a végső 
PDF változatot, amelyben ott volt valamennyi jó minőségű 
kép. Az xpdf segítségével 20090-ra nagyítottam a képeket, 
majd beindítva a The GIMP-et leolvastam az xpdf megjele- 
nítő ablakát. Kivágtam a grafikus képeket és elmentettem 
JPEG formátumban. Igaz beletelt egy kis időbe, amikor 
azonban elkészült, gyönyörű, könyv-minőségű képekhez 
jutottam, amelyeket már be lehetett importálni az Impress 
bemutatóba. Miután ezzel elkészültem, elmentettem az 
Impress dokumentumot PowerPoint formátumban és a fel- 
adat meg volt oldva. A kezdeti 20 napos becslésem körülbe- 
lül 20 órás tényleges munkára csökkent. 

Ráadásul most már, ha gyorsan kell diákat összeraknom, 

a szöveges tartalmat akár kézzel, vi segítségével is összerak- 
hatom, majd a produce slides parancsfájl lefuttatása után 
már készen is vagyok. 


Zárszó 

Ami először lehetetlen feladatnak tűnt — programozottan 
létrehozni egy PowerPoint bemutatót — kiderült, hogy 

a nyílt forráskódnak köszönhetően nagyon is lehetséges. 

A megszokott Red Hat 9 terjesztésemben valamennyi szük- 
séges eszköz rendelkezésemre állt: vi, unzip, Perl, xmilint, 
xpdf, The GIMP és az OpenOffice.org csomag. 


Linux Journal 2005. április, 132. szám 


Paul Barry (paul.barryOitcarlow.ie) 

A Carlow-i Műszaki Intézetben tart előadá- 
sokat, Írországban. Weblapján előadásaival, 
könyveivel és cikkeivel kapcsolatos informáci- 
ókat találunk: glasnost.itcarlovw.ie/— barryp. 
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Készítsünk Live CD-t! 


Készítsük el saját, különleges live CD terjesztésünket az itt bemutatásra kerülő 
nem túl ismert rendszerindító CD trükkök alapján. 


iztosan mindenki hallott már a Knoppixról, 
HB arról a Debian alapú terjesztésről, amely 2GB 
alakalmazást zsúfol egyetlen CD lemezre. Használ- 
ják Linux bemutató eszközként, mentőlemezként, sőt még 
Debian telepítőként is. Hasonló projektek egész kis seregét 
ihlette, az egy-két plusz és mínusz csomagot tartalmazó 
Knoppix CD-ktől kezdve egészen a rendszer teljes újrater- 
vezéséig. 
Jómagam mostanában fogtam neki egy termékbemutató 
CD készítésének. Kíváncsiságtól hajtva darabokra szedtem 
a Knoppix CD-t míg végül egy Makefile és néhány mellékes 
állományra jutottam, amelyek ugyan elég egyértelműen 
Knoppix ihletésűek de azért van bennük némi új kód is. 
Itt tartok most. 


Rövid Körséta 

Ha a Knoppix CD-t betesszük a meghajtóba és felcsatoljuk, 
hamar feltűnik, hogy nem nagyon hasonlít a hagyomá- 
nyos Linux telepítésekre. Van ugyan néhány grafikus fájl 
és néhány zenesáv, de nincs init, nincs /dev és nincs /bin. 
A mágia a /KNOPPIX/KNOPPIX nevű, igen méretes állo- 
mányban van, amely a cloop eszközzel tömörített 1509660 
lenyomat. 

A rendszermagban található megszokott loop eszköz lehe- 
tővé teszi, hogy néhány fájlrendszeren úgy érjük el az állo- 
mányokat mintha azok valódi eszközök lennének. Az esz- 
köz blokkjainak elérési kérelmei az alatta elhelyezkedő állo- 
mány blokkjaira fordítódnak le. Mivel az eszközt fel tudjuk 
csatolni a fájlrendszerek másolatait lényegében ugyanúgy 
érhetjük el mintha valódi lemezes eszközök lennének. 
Amennyiben a hálózatról töltöttük le a Knoppixot, akkor 
minden bizonnyal van egy 1S09660 lenyomatunk amit 

a loop segítségével fel tudunk csatolni, ha kíváncsiak 
vagyunk a tartalmára: 


ff mkdir /tmp/knoppix-cd 
$ mount -o loop -rN 
$HOME/KNOPPIX. V3.3-2003-09-24-EN.iso /tmp/knoppix-cd 


A cloop tömörített loop eszköz még egy lépéssel tovább 
megy. Ez a loop eszköz úgy modellezi az alkatrészt, 

hogy minden blokkot a gzip-pel tömörít, amit eléréskor 
átlátszó módon kibont. A /KNOPPIX/KNOPPIX pontosan 
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ilyen másolat, amelyet rendszerindításkor csatolunk fel 

— ezzel a trükkel tud a Knoppix 2GB-ot elhelyezni egy 
650MB-os CD-n. 

Ha csak egyszerűen körbe szeretnénk nézni a fájlrendsze- 
ren, nem muszáj a rendszermagunkba fordítanunk a cloop 
képességet. Elegendő a cloop-utils csomagot feltennünk és 
az extract compressed fs segédeszközt használnunk. Az ál- 
lomány elhelyezéséhez körülbelül 2GB szabad helyre lesz 
szükségünk a /var/tmp vagy valamely egyéb könyvtárban: 


ff mkdir /tmp/knoppix-ciloop 
f extract compressed fs XN 
/tmp/knoppix-cd/KNOPPIX/KNOPPIX N 
5/var/tmp/KNOPPIX-ciloop 
ff mount -o loop /var/tmp/KNOPPIX-cloop N 
/tmp/knoppix-cloop 
ft find /tmp/knoppix-cloop -print 


Mindent a szemnek, semmit a kéznek - az IS09660 fájl- 
rendszer csak olvasható. A terjesztés módosításához először 
is mindkét fájlrendszer szerkezetet egy hagyományos 
könyvtárba kell másolnunk: 


ft mkdir $HOME/my-knoppix-tree NM 
$HOME/my-knoppix-cd-tree 

ff tar -C /tmp/knoppix-cloop -cf - . [DN 
tar -C $HOME/my-knoppix-tree -xvpf - 

ff tar -C /tmp/knoppix-cd -cf - . DN 
tar -C $HOME/my-knoppix-cd-tree -xvpf - 

f$ umount /tmp/knoppix-cd /tmp/knoppix-cloop 


Most már nekiláthatunk megvalósítani szívünk vágyát. 
A legkényelmesebb módszer, ha a Knoppix belső fában 
a chroot paranccsal megváltoztatjuk a gyökeret: 


f mount -t proc none $HOME/my-knoppix-tree/proc 
ff cp /etc/resolv.confXN 
$HOME/my-knoppix-tree/etc/resolv. conf 

tt chroot $HOME/my-knoppix-tree /bin/sh 


Ettől kezdve a szokásos Debian csomagkezelő parancsok 
segítségével (dpkg, apt-get és a többiek) telepíthetünk és 
törölhetünk tetszés szerint. Miután elkészültünk, lépjünk ki 











a chroot-ból és csatoljuk le a proc-ot ( hacsak nem akarjuk 
halhatatlanná tenni a fejlesztői rendszerünk folyamatlistáját 
a CD-n). A create compressed tree és mkisofs paran- 
csokkal készítsük el a külső és belső fát: 


$ mkisofs -L -R -] -V "KNOPPIX IS096607 -vY 
-allow-multidot $HOME/my-knoppix-tree [NN 

create compressed fs - 65536 5 
$HOME/my-knoppix-cd/KNOPPIX/KNOPPIX 

$ mkisofs -] -r -J -V "KNOPPIX with local stuffféN 
-hide-rr-moved -v -b KNOPPIX/boot-en.img N 

-Cc KNOPPIX/boot.cat -o knoppix.isoN 
$HOME/my-knoppix-cd 


Végül, írjuk ki a knoppix.iso-t egy CD-ROM-ra és indíthat- 
juk a rendszert. Akár írás nélkül is kipróbálhatjuk Bochs 
vagy VmWare segítségével. 


Következő lépés 

Ez az egyszerű megközelítés azonban kezd nehézkessé vál- 
ni amikor komolyabb vállalkozásba fogunk. Például, ha azt 
szeretnénk, hogy az X egy adott ablakkezelőt indítson de 
nem akarjuk, hogy GNOME vagy KDE-t használjon, kény- 
telenek leszünk belenyúlni a parancsfájlokba. Ez persze 
nem nehéz feladat, viszont azt jelenti, hogy lényegében 
Knoppix leágazást készítünk. Amikor egy új Knoppix ver- 
zió jön ki, mindent újra meg kell csinálnunk. Továbbá, ha 
üzleti céllal szeretnénk eladni a Knoppix alalpú CD-nket, 
meg kell felelnünk valamennyi terjesztésre szánt program 
engedélyének, ami feltételezi hogy pontosan tudjuk mi 
van a lemezen. Az általam vizsgált Knoppix verzió tartal- 
mazott néhány olyan állományt amelyek nem Debian 
csomagokból származtak, sőt, némelyik még csak nem 

is volt szabad program. 

Nem közelíthetnénk meg a problémát más oldalról? 
Szerencsére megtehetjük. Hála a Progeny kezdeményezés- 
nek, amely telepítőjét ajándékozta a Debian Projektnek, 
Klaus Knoppernek a Knoppix szerzőjének és a cloop meg- 
hajtó alkotójának, és más Debian fejlesztőknek akik kódját 
a fő Debian tárhelybe felvették, ma már nulláról össze tu- 
dunk állítani egy teljes live CD rendszert kizárólag Debian 
csomagok segítségével. A cikk további részében ezzel 
fogunk foglalkozni. 


Letöltések 

A cikkünkben szereplő parancsfájlok és állományok 
tarlabdája a következő címről tölthető le: 

ftp.lVinux.org.uk/ -dan/livecd. Helyszűke miatt cikkünkben 
a legtöbb kódot nem mutatjuk be. Többnyire Makefile által 
vezérelt, pár héjprogrammal és néhány egyszerű Perl 
kóddal megtűzdelve, úgy gondolom elég jól követhető. 
Kicsit nehezebb dolga van annak aki nem Debiant használ. 
Ha sikerül más terjesztés alatt is működésre bírni a dolgot, 
kérem küldjék el a foltot. 

A debootstrap program az további munkához szükséges 
Debian alaprendszert biztosítja. Ha megadjuk a Debian 
kiadás nevét és a csomagtükör URL-t, a debootstrap a kivá- 
lasztott alkönyvtárba tölti le és telepíti az alaprendszer. 

Ez igen rugalmas megoldás. Beléphetünk chroottal, 
használhatjuk UML gyökérként, avagy, ha a kiválasztott 
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alkönyvtár külön fájlrendszer volt, újraindíthatjuk a gépet 
és közvetlenül is használhatjuk. Akár CD-re is kiírhatjuk, 

és pontosan ezt akarjuk majd tenni. De addig még van egy 
két elvégzendő feladatunk. 

A parancsfájljaink próbálgatása folyamán jó sok debootstrap 
és csomagtelepítésre számíthatunk. Mielőtt továbblépnénk, 
egy kis időt és sávszélességet takaríthatunk meg, ha felte- 
szünk valamilyen proxy csomagarchívumot (például az apt- 
proxy-t) egy kényelmesen elérhető gépre. 


Csomagok felvétele 

A Makefile-ban található fix inner cél csomagokat ad az 
alaprendszerhez. Első lépésként lecseréljük a start-stop- 
daemon programot a /bin/true-ra, nehogy az telepítés utáni 
(post-installation) parancsfájlok szolgáltatásokat indítsanak 
el a chroot környezetünkben. Ez után többször chroot-olunk 
a rendszerbe és futtatjuk az apt-get és dpkg parancsokat. 
Tesztelési és kísérletezési célokra a run-chroot.pl Perl 
parancsfájlt használhatjuk, amely rendszerindítást szi- 
mulál chroot környezetben. A legtöbb szolgáltatást 

nem indítja el, hiszen azok már elve futnak a gépen és 
ütközést okozhatnának, de az SSH kiszolgálót és az X 
indítószkripteket lefuttatja. Sokkal kényelmesebb mint 
mindig kiírni egy CD-t és újraindítani a gépet valahány- 
szor ki akarjuk próbálni. 


autologin 

Nem sok értelme van bejelentkezésre kényszeríteni az em- 
bereket egy egyfelhasználós, bemutatóra szánt rendszeren. 
Úgyis meg kell mondani nekik a jelszót, és mivel a CD csak 
olvasható legfeljebb ideiglenesen tudják megváltoztatni azt. 
A GDM rendelkezik ugyan autologin képességgel, de mivel 
a méretet nem szeretnénk túlságosan megnövelri, jobb 
lenne elkerülni a rengeteg GNOME függőséget. Ehelyett 
egyszerűen a su paranccsal indítjuk az X-et nem-rooct fel- 
használóként, és lefuttatjuk az .xsession parancsfájlt, amely 
beindítja az xterm-et, az Emacs-ot és az alkalmazásainkat. 
Az autologin-x parancsfájl /etc/init.d.autologin-x néven tele- 
pül, és elkészíti a rendszerindítás folyamatába illesztéshez 
szükséges közvetett hivatkozásokat. 

A parancsfájl a DISPLAY változó értéke alapján dönti el, 
hogy melyik X kiszolgálót szükséges futtatni. Ha már be 
van állítva, az Xvnc-t indítja az XFree86 helyett. Ez a teszte- 
lést segíti: amikor az autologin-x-et a run-chroot.pl futtatja 
egy xterm ablakban, hozzákapcsolódhatunk egy VNC 
ügyféllel és meggyőződhetünk róla, hogy valamennyi 

X alkalmazás megfelelően indul. Természetesen ha az 
CD-ROM-ról indítva szeretnénk futtatni az X-et, tudnunk 
kell, a felhasználó milyen videókártyával rendelkezik. 


Alkatrészfelderítés 

A Linux alkatrész-felderítési képességei igen sokat fejlődtek 
az utóbbi tíz évben, amit az alkatrész-technológiák fejlődé- 
se is elősegített. Egy mai PCI vagy USB alkatrészt sokkal 
könnyebb megbízhatóan és biztonságosan azonosítani 
mint egy korabeli ISA csatolót. 

A legtöbb Linux terjesztésben találunk valamilyen megol- 
dást, amely végigvizsgálja a rendszer PCI és USB eszközeit 
és betölti a megfelelő modulokat. A Knoppix a Kudzut hasz- 
nálja, amit eredetileg Red Hat-hez írtak, az eredeti Debian 


2005. július 99 


0 Kiskapu Kft. Minden jog fenntartva 








Szaktekintély 


0 Kiskapu Kft. Minden jog fenntartva 





pedig a discover parancsot alkalmazza. A két megoldás 
alkatrész lefedettsége közel azonos; tekintve, hogy mind 

a kettő nyílt forrású, nyugodtan másolhatnak egymás alkat- 
rész adatbázisából. A Debian X kiszolgáló csomagja eleve 

a discover segítségével állapítja meg az X beállítási kérdé- 
sek alapértékét, így inkább ennél maradunk. 


dehconf 

Mit kezdünk a felderített alkatrészekkel? A Debian csoma- 
goknak kézzel szerkeszthető beállításállományuk van, de 
általában telepítés-utáni parancsfájlokkal interaktív módon 
hozzák létre azok kezdeti verzióját telepítéskor. Amikor 
megoldható, mint például az X és hálózati beállítások 
esetében, a parancsfájlok lefuttatják az alkatrész kereső 
eszközöket. 

A gond csak az, hogy mi jelenleg chroot környezetben 
telepítünk a gazdagépen, és a gazda alkatrészeinek fel- 
derítése nem sokat segít a célgépen. Ezért a debconf adat- 
bázisát valami írható helyre kell tennünk, így indításkor 
a debconf-communi cate segítségével törölhetjük a csoma- 
gok beállításait, majd a .config parancsfájlok futtatásával 
elhitetjük velük, hogy első ízben állítjuk be őket. Ez alapo- 
sabb megközelítés mint a dpkg-reconfigure futtatása, 
ami néha olyanokat kérdez mint: , Biztos, hogy újra be 
kívánja állítani a csomagot?". Ez megzavarhatja a végfel- 
használót aki természetesen még semmit sem állított be. 
A debconf-communi cate kézikönyvoldalain és a tarlabda 
target/etc/init.d/configure-xserver állományában további 
részleteket találunk. 


Maradandó tároló: Hotplug 

A CD-ROM csak olvasható, a ramdisk megsemmisül amint 
a gépet lekapcsoljuk. Az emberek viszont el szeretnék men- 
teni az állományaikat, illetve el akarják érni a meglévő me- 
revlemezeiken és cserélhető tárolóikon (például USB kul- 
cson vagy ZIP meghajtón) őrzött állományokat. Akárcsak 
az előbb, a munka legnehezebb részét már elvégezték he- 
lyettünk; most a hotplug és az autofs lesz a megmentőnk. 

A hotplug az új eszközök behelyezését és eltávolítását figye- 
li. Amikor új USB tárolóeszközt vesz észre, betölti a megfe- 
lelő modulokat és emulált SCSI gazdát hoz létre. Továbbra 
is nekünk kell tudnunk azonban, hogy milyen eszközök 
állnak a rendelkezésünkre és nekünk kell kézzel felcsatolni 
őket, itt jön a képbe az autofs. 

Az autofs igény szerint fel- és lecsatolja a fájlrendszereket. 
A map program használatával egy Perl parancsfájlt futtat- 
nunk valahányszor a felhasználó lekérdezi a /media/list 
könyvtárat; itt létrehoz egy könyvtárat, valamint elkészíti 

a csatlakoztatott eszközök nevének megfelelő közvetett hi- 
vatkozásokat. A hivatkozások autofs csatlakoztatási pontok- 
ra mutatnak melyeken keresztül elérhetjük a fájlrendszert. 
Vizsgáljuk meg a target/etc/auto.master és target/usr/local/ 
sbin/autofs-device-list állományokat a tarlabdában. 


A rendszermag 

Lényegében ugyanazt a rendszermag beállítást használjuk 
mint a Knoppix (vizsgáljuk meg egy futó Knoppix rendszer 
fusr/src/linux/.config állományát, vagy a tarlabdánk kernel- 
config állományát), de eltávolítunk belőle néhány számunk- 
ra nyilvánvalóan felesleges dolgot, például a ZISOFS-t. 
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A szabványos Debian make-kpkg eszközcsomagok felépítik 
és telepítik a rendszermagot. A gazdagépen található 
Debian függőségről van szó (szükségünk lesz a cloop-src 
csomagra), és mivel valószínűleg ez az egyetlen ilyen nem- 
egyértelmű függőség, a későbbi verziókban esetleg érdemes 
lehet áthozni a chroot-ba. 


A fájlrendszer 

A legtöbb UNIX fájlrendszer szívesen elindul csak olvasha- 
tó módban is, ám nekünk néhol szükségünk van fájlírásra. 
Például az X kiszolgáló beállításállományait indításkor 

a használt alkatrészeknek megfelelően át kell alakítanunk, 
a debconf adatbázist frissítenünk kellene illetve vannak 
különféle napló és zár-állományaink is. 

A tmpfs fájlrendszer segítségével RAM-alapú fájlrendszert 
hozunk létre. A rendszer ezt a memórialemezt fogja hasz- 
nálni gyökérként és a /ro alkönyvtárban várja a CD lemez 
felcsatolását. A csak olvasható könyvtárakhoz közvetett 
hivatkozásokat hozunk létre, például a /usr-t a /ro/usr-hez 
rendeljük. 

A csak olvasható könyvtárakról listát készítünk, és kétszere- 
sen ellenőrizzük. Először egy tarlabdát készítünk a rend- 
szerről amely nem tartalmazza ezeket a könyvtárakat, he- 
lyükön a megfelelő közvetett hivatkozásokkal. Ezt a tarlab- 
dát aztán a futó rendszer gyökerébe másoljuk. Másodszor, 
amikor a 1509660 képmást cloop-tömörítéssel kiírjuk, ezt 

a könyvtárlistát fogjuk csatolni. 


initrd 

Mielőtt a rendszer beindulna két igen fontos dolgot kell 
elintéznünk. Először is fel kell csatolnunk a cloop másolatot, 
szükség szerint be kell töltenünk a CD-ROM modulokat, 
majd meg kell találnunk és fel kell csatolnunk a CD-t. Ezek 
után telepítjük a cloop eszközt majd felcsatoljuk rá a belső 
fájlrendszert. Másodszor elkészítjük a gyökér fájlrendszer- 
hez a memórialemezt és rámásoljuk a roof fs.tgz tartalmát 
a CD-ről. 

Az initrd (initial ramdisk) támogatás segítségével készítünk 
egy mini gyökér rendszert amit a rendszermag felcsatol 

és lefuttat mielőtt a valódi init elindulna. Ez gzippelt fájl- 
rendszer lesz. Amikor initrd támogatással rendelkező 
rendszermagot indítunk a initrd-filename paraméterrel, 
a megadott fájlnév tartalmát fogja betölteni és memóriale- 
mezt készít belőle. Ez után memórialemezen elindítja 

a /linuxrc állományt. 

Amikor a linuxrc befejeződött, a pivot root hívást használja 
a valódi gyökér fájlrendszerbe váltáshoz (amely addig 

a /ramdisk volt) majd lefuttatja a valódi init-et. 

A rendszermag és az initrd, az indítómásolat valamennyi 
állományát beleszámolva, elég kicsi kell legyen, hogy 
beleférjen 1.44MB memóriában. Ez nem valami sok hely, 
hiszen a GNU önmagában 1,200K, úgyhogy kreatívnak 

kell lennünk. 


dietlibc, Busybox 

Aki soha még csak nem is vágyott Linuxos PDA-ra 

vagy autóba építhető MP3 lejátszóra, most az is igazán 
hálás lehet a beágyazott Linux programozóinak. 

A Busybox és dietlibc segítségével fogjuk ugyanis átjuttat- 
ni a tevét tű fokán. A busybox apró héjprogram amit fordí- 


















root fs.tgz 
unpacked into root 


/CIRCLE/CLOOP ramdisk by /linuxrc 


cloop-pal tömörített is09660 fájlrendszer 








1. ábra Doboz a dobozban: a kész CD fájlrendszer másolatba ágyazott 
fájlrendszer másolatban megbúvó fájlrendszer másolatokat tartalmaz 


táskor beállíthatunk úgy, hogy beépítettként tartalmaz- 
zon sok általános eszközt, a dietlibc pedig egy kis méret- 
re optimalizált C könyvtár változat. Örömmel vehetjük 
észre, hogy a busybox mindent tud, amire az initrd-ben 
szükségünk lehet, valamint hogy statikusan fordítva 

a dietlibc-vel mindössze 100K helyet foglal. Összeha- 
sonlításképpen ugyanezekkel a Busybox kapcsolókkal 
statikusan fordítva a glibc-vel 500K méretű végrehajtható 
állományt kapunk. 

A Busybox bővítményeit a (tarlabdában található) Config.h 
állomány ídefine kulcsszavaival kapcsolhatjuk be. A ki- 
kapcsolt értékek talán önkényesnek tűnhetnek, de amikor 
könyvtárlista kérésére használhatjuk az echo " és tar cvf 
/dev/nul1 parancsokat is, az 1s igazán luxusnak tűnik. 

Az initrd-t a genext2fs programmal készítjük, így nem lesz 
szükségünk loopback felcsatolásra. A program egy könyv- 
társzerkezetből készít ext2 fájlrendszert, amit gzip-el tömörí- 
tünk és a rendszerindító lemezmásolatba mozgatunk 
(1.ábra). 


Rendszerindítás 

A CD-ROM-ról történő rendszerindítás szabványa El Torito 
néven vált ismertté amit eredetileg a Phoenix BIOS készítői 
hoztak létre. Az El Torito egy vagy több lemezképmás létre- 
hozását teszi lehetővé a CD lemezen. Rendszerindításkor 

a BIOS felderíti ezeket, szimulált lemezt hoz belőlük létre 
és erről indítja a rendszert. A másolatok hajlékony lemez 
(1.44MB vagy 2.88MB) illetve merevlemez másolatok lehet- 
nek. Ezen kívül létezik nem-emulációs mód is, ahol a BIOS 
egy megadott állományból tölt be szektorokat és emulált 
lemez kialakítása nélkül hajtja végre azokat. 

Természetesen itt is van buktató: Az E! Torito rendszert 
BIOS írók készítették. A laptoppal vagy egyéb érdekes al- 
katrésszel rendelkező Linux tulajdonosok jól tudják, hogy 
a BIOS-ok nem éppen a leginkább hibamentes programok 
ezen a földön. Nem ok nélkül feltételezhetjük, hogy bizo- 
nyos gyártók nyugodt szívvel hagyják figyelmen kívül a hi- 
vatalos rendszerleírásokat mindaddig, míg szerkezetük az 
éppen aktuális Windows rendszer alatt valahogy elindul. 
Így aztán akármilyen fájdalmas is a méretbeli korlát, a ma- 
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ximális hordozhatóság érdekében a Knoppix által kijárt utat 
fogjuk követni és egyetlen 1.44MB hajlékonylemezes máso- 
latot alkalmazunk. 


hoot.img 

Mit tegyünk ebbe az 1.44MB-ba? Indíthatunk nyers Linux 
rendszermagot, esetleg használhatjuk a megszokott LILO 
vagy Grub Linux rendszerindítót. H Peter Anvin SYSLINUX 
eszköze azonban használhatóság terén mindkét lehetőséget 
könnyedén veri. A SYSLINUX MS-DOS fájlrendszert hasz- 
náló indítólemezeket készít, így a hajlékonylemez másola- 
tot a felhasználói mtools segítségével is létrehozhatjuk. 

A lemeznek a rendszermag vmlinuz állományra, 

a syslinux.cfg, csatolt segítségnyújtó állományokra és az 
initrd másolatra van csak szüksége. Amint készen vagyunk 
futtathatjuk rajta a SYSLINUX-ot. 

Már csak az maradt hátra, hogy elkészítsük és kiírjuk 

a fájlrendszerünket, amint azt korábban is tettük. A belső 
fájlrendszer a $(SCRATCH) /CLOOP-ban található. A külső fájl- 
rendszerünk a boot.img és root fs.tgz állományokat tartal- 
mazza majd. Ezt kiírjuk a CD-re (egy-két CD-RW lemez 
sem árthat) majd elindítjuk róla a gépet. Hacsak nincs nagy 
balszerencsénk, működni fog. 


Végszó 

Számomra, régi Linux felhasználó számára, aki szokásos te- 
lepítést már évek óta nem csinált, igazán lenyűgöző, hogy 
milyen sokat fejlődött az automatikus alkatrész felismerés 
és támogatás. És ahogy telik az idő, biztos vagyok benne, 
hogy még ennél is csak jobb lesz. 

Merre lehet továbblépni? Az automount támogatáson 

kell kicsit csiszolni; esetleg kipróbálhatunk valami mást, 
például a Volumatic-ot. A többi leginkább a készülő termé- 
künktől függ. Azonban minden parancsfájl szabad prog- 
ram, és érdeklődve várom a visszajelzéseket. 


Linux Journal 2005. április, 132. szám 


Daniel Barlow független szakértő az Angliai Ox- 
" fordban, ahol Linux és Common Lisp fordítókkal 
§ dolgozik. Szabadidejében, nagyon szeret elekt- 
romos gitáron rosszul játszani, ami nagy szeren- 
cse, ugyanis csak így tud. Megjegyzéseket 

a danometacircles.com címen várja. 
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InfiniBand és Linux 


Vajon miért is jó, ha a hálózatunk távoli rendszere irkálhat a memóriánkba, 
hogyan küldhetnek felhasználói programok a rendszermag zaklatása nélkül 
adatokat, valamint néhány újabb adalék a nagy sebességű kapcsolattartásról. 


osszú vajúdást követően végül megszületett az 
HA] InfiniBand (IB), sőt a Linux IB támogatása is már 
fejlesztés alatt áll. Fizikai szinten az IB nagyon 
hasonlít a PCI Express-re. Az adatokat több nagy sebességű 
soros csatornán továbbítja. Az InfiniBand első változatának 
leírása valamennyi csatornán azonos jelzésszélességet enge- 
délyezett, mégpedig 2.5Gb/5-ot, akárcsak a PCI Express. 
A leírás legutóbbi változata (1.2), ugyanakkor már támogatja 
a csatornánkénti 5Gb/s és 10Gb/s sebességeket. Ezen kívül 
az IB az 1X, 4X, 8X és 12X, míg a PCI Express a XI, X2, X4, 
X8, X12, X16 és X32 szélességeket támogatja. A leggyakrab- 
ban használt IB sebesség manapság a 4X 2.5Gb/s/csatorna 
sebesség mellett, azaz összesen 10Gb/s. A 12X szélesség 
a 1OGb/s/csatorna sebességgel kombinálva azonban a jelen- 
legi IB leírás szerint akár a lenyűgöző 120Gb54s átviteli telje- 
sítményt is támogatja. 
Minthogy az IB általában hálózatépítésre használatos, a réz 
és optikai kábelezést egyaránt támogatja, míg a PCI Exp- 
ressz kábelmeghatározásai még fejlesztés alatt állnak. 
A legtöbb IB telepítés rézkábelezést alkalmaz (1. ábra) 
amely körülbelül 10 méterig használható. Az IB ezen 
kívül lehetővé tesz optikai kábelezést is, amely elméletileg 
akár 10 kilóméterig is használható. 


Technológia 
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Adatátviteli sebesség 


Az elmúlt években az IB-t tekintették a PCI utódjának, de 
manapság már nem ez a helyzet. Az IB adapterek továbbra 
is inkább külső eszközök maradnak amelyek PCI, PCI 
Express, HyperTransport vagy hasonló periféria buszokon 
keresztül csatlakoznak a rendszerhez. 

A rendszereket az IB hálózathoz csatoló hálózati eszközt 
Host Channel Adapternek (HCA) nevezik. Az eszköz igen 
magas sebessége mellett az IB HCA egy üzenetközvetítő 
felületet is biztosít, melynek segítségével az InfiniBand 
10Gb/sec (vagy még nagyobb) sebességét ki tudják aknázni 
a rendszerek. Az IB sebességének kihasználásának kulcsa 
a zéró másolású hálózatkezelés támogatása; máskülönben 
az alkalmazások egyfolytában csak az adataikat másolnák. 
A zéró másolást a HCA felület három kulcseleme teszi le- 
hetővé: az elvont, magasszintű munkasor, a rendszermag 
megkerülés és a távoli közvetlen memória elérés (Remote 
DMA; RDMA). Az elvont munkasor annyit jelent, hogy 
az alkalmazások nem csomagról csomagra formálják 
meg és dolgozzák fel a hálózati csomagokat, hanem 
kérelmeket küldenek a HCA által kezelt soroknak. 

Egy munkakérelmen belül küldött üzenetet legfeljebb 
4GB hosszú lehet. A HCA felügyeli az üzenet csomagok- 
ra tördelését illetve várakozik a jóváhagyásokra és küldi 


Kábelezés 

















1. ábra Felülről lefelé: cat5 Ethernet kábel, 
4X InfiniBand kábel és 12X InfiniBand kábel 
(méretarány kedvéért egy negyeddolláros érme látható) 


1. lista IPolB Meghajtó alaphelyzetbe állítása 


SERUuct ibegpoginikeéasEMani Sat esze 
: cap — ii 
.max send wr 
.max recv wr 
.max send sge 
.max recv sge 


FROTBETXERENGÉSTZE; 
"EPOTBERXERENGEÉSTEZE; 
1, 

TE 


HE 
.sgd.sig.type - IB SIGNAL ALL MR, 
.racsig type - IB SIGNAL ALL WR, 
. ap.type STB ZOPTEÚD 
HB 
priv-spd - ib alloc pd(priv-3ca); 
priv-scg - ib create cg(priv-sca, 
ipoib ib completion, 
NULL, dev, 
IPOIB TX RING SIZE - 
IPOIB RX RING SIZE 4 1); 
if Cib reg notify cg(priv-scg, IB CO NEXT. COMP)) 
goto out free cg; 
priv-smr - ib get dma mr(priv-:pd, 


IB ACCESS LOCAL WRITE); 

üntezattessendéeg Priv-zeg; 
INnTteattr.recvLegi — priv-:seg, 

priv-sgp - ib create gp(priv-spd, ginit attr); 


újra az elveszett csomagokat. Mivel a HCA alkatrész 
felügyeli a nagyméretű üzenetek kézbesítését bármiféle 
CPU felhasználás nélkül, az alkalmazások több CPU 
időt használhatnak fel a küldött és fogadott adatok 
elkészítéséhez és feldolgozásához. 


www.linuxvilag.hu 





A rendszermag megkerülése lehetővé teszi, hogy az al- 
kalmazások közvetlenül küldjenek munkakérelmeket és 
fogadjanak befejezési eseményeket a HCA sorairól, így 

a rendszerhívásokkal járó felesleges környezetváltás elke- 
rülhető. A rendszermag meghajtó beállítja a sorokat, ahol 

a szokásos memória védelem gondoskodik arról, hogy min- 
den folyamat csak a saját erőforrásait érje el. Valamennyi 
nagysebességű irányítási (path) művelet ugyanakkor a fel- 
használói térben megy végbe. 

Az utolsó elem, az RDMA, lehetővé teszi, hogy az üzenet 
magával vigye a célcímet ahová a memóriában majd kerül- 
nie kell. Az adat helyének megadása például az IB alatti tá- 
rolók kialakításakor lehet hasznos, ahol a kiszolgáló lemez- 
olvasásai teljesen rendszertelenek lehetnek. RDMA nélkül 
vagy a kiszolgálónak kell időt pazarolnia mikor áll elküldés- 
re készen az adat vagy az ügyfélnek kell CPU erőt pazarol- 
nia az adatok végső helyre másolásához. 

Bár a távoli rendszerek memóriájába firkálással szem- 

ben vannak bizonyos fenntartások az IB használó alkal- 
mazások szigorú határokat és jogosultságokat állíthatnak 
be az RDMA szolgáltatásnak. Az IB RDMA legalábbis 
biztonságosabb dolog mint a lemezvezérlő DMA-ját 

a memóriába engedni. 

Nagy sebességén felül, az IB egyúttal a fürtök (clusters) 
készítését és kezelését is leegyszerűsíti, hiszen egyetlen 
eszköz szállítja a hálózati és tároló forgalmat valamint 

a fürt kommunikációt. Több csoport is hozott létre külön- 
féle IB felett futtatható felső szintű protokollokat, néhány 
ezek közül: 


e . IP-over-InfiniBand (IPoIB): az Internet Engineering Task 
Force (IETP) szabványfejlesztő munkacsoportja az IB 
alatti IP forgalomküldés ösvényét tapossa ki. Ezek az 
ösvények idővel a IpolB REC szabványává válhatnak. 
Az IPolB ugyanakkor nem használja maximálisan ki 
az IB képességeit, hiszen a forgalom továbbra is az IP 
vermen keresztül utazik és csomagról csomagra kerül 
elküldésre. Az IPoIB egyszerű lehetőséget biztosít 
régebbi alkalmazásaink futtatására vagy a vezérlőfor- 
galom átküldésére IB-n keresztül. 


e  Sockets Direct Protocol (SDP): az InfiniBand Trade 
Association maga adott meg egy olyan protokollt, amely 
a szabványos socket műveleteket helyi IB RDMA műve- 
letekké alakítja. Ezáltal a socket alkalmazások változta- 
tás nélkül futtathatók, ugyanakkor az IB teljesítményé- 
nek szinte minden előnyét élvezhetik. 


e  SCSI RDMA protokoll (SRP): a SCSI szabványokért fele- 
lős InterNational Committee for Information Technology 
Standards (INCITS) T10 bizottság, kiadott egy szab- 
ványt, amely leírja hogyan kell a SCSI protokollt az 
IB-hoz rendelni. A második generációs SRP-2 protokoll 
fejlesztése jelenleg folyik. 


Sok más csoport is tanulmányozza az IB kihasználási lehe- 
tőségeit, például a DAT Collaborative és az Open Group 
Interconnect Software Konzorciuma készített API-kat, 
RDMA csatolásokat az NFS-hez valamint IB támogatást 
különféle MPI csomagokhoz. 
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2. lista IPolB meghajtó küldési kérelem feladása 


priv-stx sge.lkey - priv-smr-slkey; 


priv-5tx sge.addr szadds 
priv-5tx sge. length z len; 
priv-5tx wr.opcode - IB WR SEND; 


priv-stx wr.sg list - €priv-ostx sge; 
priv-5tx wr.num sge Sal 

priv-5tx wr.send flags - IB SEND SIGNALED; 
priv-stx wr.wr id z ME Ul 

priv-stx wr.wr.ud. remote gpn - gpn; 

priv-stx wr.wr.ud.ah z address; 


ib post send(priv-sgp, €priv-stx wr, §bad wr); 


Természetesen nyílt forráskódú támogatás nélkül az egész 
csinos eszköz nem lenne különösebben érdekes a Linux 
világban. Szerencsére az OpenIB Alliance ipari szövetség 
feladata pontosan az, hogy egy teljesen nyílt forrású IB 
vermet hozzon létre. Az OpenIB jelenleg 15 tag-céggel 
rendelkezik, amelyek között egyaránt találunk IB alkatrész 
terjesztőket, kiszolgálócégeket, programcégeket és kutatási 
szervezeteket. 

Az OpenIB programon 2004 februárjában kezdődtek 

meg a munkálatok, az első rendszermag meghajtó 

pedig 2004 decemberében került a rendszermag fába, 
közvetlen azután, hogy a 2.6.10-es kiadás után megszüle- 
tett a 2.6.11-es fa. A rendszermagba illesztett első IB meg- 
hajtó kód csomag éppen csak annyit tud, hogy már azért 
működőképes. Tartalmaz egy középréteget, amely elfedi 
az alacsonyszintű alkatrészmeghajtókat a felsőszintű 
protokollok elől, egyetlen alacsonyszintű meghajtót 

a Mellanox HCA-hoz, valamint egy IPolB felsőszintű 
protokoll meghajtót amellyel egy alhálózat kezelőt futtat- 
hatunk a felhasználói térben. 

Az IPoIB meghajtó kódjának néhány apró részlete sokat 
elárulhat a rendszermag IB támogatásának felhasználási 
lehetőségeiről. Amennyiben egészében szeretnénk látni 

a kódot, a teljes IPoIB meghajtót kell megnéznünk, amelyet 
egyébként a Linux forrásfájának drivers/infiniband/ulp/ipoib 
könyvtárában találjuk meg. 

Az 1. lista bemutatja, mit is csinál az IPolB meghajtó 

az IB erőforrások lefoglalásához. Először meghívja az 

ib alloc pd() függvényt, amely lefoglalja a védelmi tarto- 
mányt (protection domain vagy PD), ez egy átlátszó tároló 
amelyre valamennyi IB felhasználónak szüksége van az 
erőforrások tárolásához. 

Itt most kihagytuk a listából a helyes hibakezelést, 

annak ellenére, hogy minden valódi rendszermag 

kód valamennyi függvény visszatérési értékét ellen- 
őrizné. Minden erőforrást foglaló és mutatót visszaadó 
IB függvény a szokásos Linux módszert alkalmazza 

a hibák visszaadására az ERR PTR() makrón keresztül, 
következésképpen az állapotot az IS ERR() segítségével 
le lehet kérdezni. Például a ib alloc pdO hívás a valódi 
rendszermag kódban a következőképpen nézne ki: 
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priv-spd -— ib alloc pd(priv-:3ca); 
if (IS ERR(priv-:pd)) ( 
printk(KERN WARNING "9ós: failed " 
"to allocate PDWn", ca-sname) ; 
return -ENODEV; 


2 


Ezek után a rendszermag meghívja az ib. create cgO 
függvényt, amely létrehozza az befejeződési sort 
(completion gueue, azaz CO). A meghajtó igényli, hogy az 
befejeződési esemény bekövetkeztekor meghívódjon az 
ipoib. ib completionO függvény, valamint, hogy a CO 
legalább IPOIB TX RING SIZE 4 IPOIB RX RING SIZE 4 1 
darab munkabefejezési struktúrát tárolhasson. Erre a mé- 
retre abban a különleges esetben van szükség, amikor 

a meghajtó a lehető legnagyobb számú üzenetet küldi és és 
fogadja majd nem tud lefutni, míg valamennyi el nem ké- 
szül. Elég zavaró módon, a CO-k olyan IB erőforrások, 
amelyek nincsenek kapcsolatban a PD-kel, ezért a függ- 
vénynek nem is kell átadnunk PD adatot. 

Amikor a CO elkészült a meghajtó az ib reg notify cgO 
függvényhez fordul és kérelmezi, hogy amikor a következő 
munkabefejezés a CO sorba kerülésére hívódjon meg a be- 
fejezési esemény függvény. Az ipoib. ib completionO 
eseményfüggvény feldolgozza a befejezéseket amíg a CO 
ki nem ürül, majd meghívja az ib. reg notify. cgO-t. 

Így újra elindul, amint újabb befejezések válnak elérhetővé. 
A meghajtó ekkor meghívja az ib get dma mrO-t amely be- 
állítja arendszermag DMA osztó API-tól kapott DMA cím- 
mel használható memóriaterületet (MR). Ennek kezeléséhez 
az IB HCA-ban to elkészülnek az átalakító táblák, és egy he- 
lyi kulcsot (L Key) adunk vissza, amelyet aztán tovább lehet 
adni a HCA-nak, és hivatkozhat az adott MR-re. 

Végül a meghajtó az ib create apO-t hívja meg, amely 
létrehoz egy sorpárt (OP). Ezt az objektumot azért neve- 
zik sorpárnak mert két darab munkasort tartalmaz. 

Egyet a küldési kérelmeknek és egyet a fogadási kérel- 
meknek. A OP létrehozásához először ki kell töltenünk 

a meglehetősen méretes ib. gp init attr szerkezetet. 

A fedőstruktúra a készítendő küldő és fogadó sorok mére- 
tét adja meg. A sa sig type és az rag sig type mezőket 
IB SIGNAL ALL. WR értékre állítjuk, így minden munkakére- 
lem befejezési eseményt vált ki . 

A gp.type mezőt IB OPT. UD értékre állítjuk, létrehoz- 

va ezzel a megbízhatatlan adatcsomag (unreliable 
datagram avagy UD) OP-t. Az IB OP esetében négyféle 
szállításról beszélhetünk: megbízhatóan összekapcsolt 
(RC) , megbízható adatcsomag (RD), megbízhatatlanul 
kapcsolt (UC) és megbízhatatlan adatcsomag (UD). 

A megbízható szállítások esetében az IB alkatrész 
garantálni tudja, hogy minden egyes üzenet vagy sike- 
resen kézbesítődik, vagy hibát jelez amennyiben a hibát 
egy javíthatatlan hiba okozza (például kihúzzuk a ká- 
belt). A kapcsolt adatszállítás esetében minden üzenet 
egyetlen célállomásra irányul, amelyet a OP beállítása- 
kor határozunk meg, az adatcsomag szállítás esetében 
minden egyes csomag különböző célokra irányulhat. 
Amikor az IPoIB meghajtó elkészítette a OP-t, a kapott 
csomagokat a OP-n keresztül küldi a hálózati verembe. 

A 2. lista mutatja be, hogy mit kell tennünk akkor, 











ha egy kérelmet akarunk helyezni a OP küldési sorába. 
Először is a meghajtó a küldési kérelemhez felállít egy 
gyűjtőlistát. Az Ilkey mező annak az MR-nek az L Key 
értékét veszi fel, amelyet az ib. get dma mrO-ből kaptunk. 
Minthogy az IPolIB olyan csomagokat küld, amelyek 
egyetlen összefüggő részben találhatóak, a gyűjtőlistában 
mindössze egyetlen bejegyzés található. A meghajtónak 
csak a címet és csomag hosszát kell megadnia. A gyűjtő- 
listában található cím nem a virtuális cím hanem 

a dma map singleO függvénnyel megkapott DMA cím 
lesz. Általánosságban a programok hosszabb gyűjtőlistákat 
is használhatnak, ezáltal rákényszerítve a HCA-t, hogy 
egyetlen üzenetbe gyűjtsön össze több puffert és így nem 
kell egyetlen pufferbe másolnia az adatokat. 

A meghajtó ezután kitölti a munkakérelem maradék mező- 
it. Az opcode-ot send-re állítja, az sg list és num sge érté- 
keket az éppen kitöltött gyűjtőlista címe kerül a send flags 
értéke pedig signaled lesz, így a munkakérelem befejezést 
vált ki amikor végez. A távoli OP számot és címkezelőt be- 
állítjuk, majd a wr. id mezőbe a meghajtó munkakérelem 
azonosítója kerül. 

A munkakérelem kitöltése után a meghajtó meghívja az 

ib post. sendŐ-et, amely végül a kérelmet felveszi a sorba. 
Amikor a kérelmet teljesítette az IB alkatrész, a munka 
teljesítése a meghajtó CO sorába kerül, amelyet végül az 
ipoib ib completionO dolgoz fel. 

Az InfiniBand rengeteg mindenre képes és az OpenIB 
Alliance éppen csak elkezdte megírni a képességeit kihasz- 
náló programokat. Most, hogy már a Linux rendelkezik az 


alapvető IB támogatással, nekiláthatunk a felsőszintű proto- 
kollok elkészítésének, ideértve például az SDP-t és a tároló 
protokollokat. A másik komolyabb terület amely jelenleg 
foglalkoztat bennünket, a közvetlen felhasználói térbeli IB 
elérés, azaz a korábban említett rendszermag megkerülő 
képesség. Rengeteg érdekes dolgot lehet még csinálni az 
IB-hez és az OpenIB Projekt mindenki számára nyitott, 
kalandra fel tehát, csatlakozz a mókához. 


Linux Journal 2005. május, 133. szám 


Roland Dreier Linux InfiniBand meghajtók karbantartója és 
vezető fejlesztője az OpenlIB.org projekt keretében. Roland 
a Kaliforniai Berkeley egyetemen szerezte matematika 
doktorátusát és több különféle titulusa volt már akadémiai 
körökben valamint a műszaki világban. 2001 óta a Topspin 
Communications alkalmazásában áll. 
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VIA PadLock - Boszorkányosan gyors titkosítás 


A VIA olcsón beszerezhető processzora támogatja az Advanced Encryption 
Standardet, így segítségével kiemelkedő szintű titkosítást végezhetünk, 


méghozzá hardveres szintű sebességgel. 


ki használt már titkosítást, az valószínűleg hamar 
A észrevette, hogy a művelethez nem csekély pro- 
cesszorteljesítményre van szükség. A régebbi rend- 
szereken például a titkosított fájlrendszerek használata las- 
sabb fájlműveleteket eredményez, az újabb rendszereken 
pedig legalábbis magasabb processzorterheléssel kell számol- 
nunk. A hálózati forgalom IPsec alapú titkosítása szintén le- 
lassítja a dolgokat, és sokszor még egy hétköznapi, 100 Mbps 
sebességű hálózaton is észlelhető a teljesítmény visszaesése. 
e A titkosítás/teljesítmény kompromisszum kezelésére 
többféle út kínálkozik: 
e "Nem használunk titkosítást: látszólag a legolcsóbb meg- 
oldás, ám hosszú távon rendkívül drágává is válhat. 
e A lassúbbodás elfogadása: a legjellemzőbb megoldás. 
e Különálló titkosításgyorsító eszköz használata: például PCI 
buszra illeszkedő kártya, amely sajnos nem javít annyit 
a helyzeten, mint várnánk, ugyanis az adatoknak a feltét- 
lenül szükségesnél többször kell megjárniuk a PCI buszt. 
e VIA PadLock technológiát használó processzor haszná- 
lata. De vajon mi az a VIA PadLock? Rögtön kiderül. 


VIA PadLock 


Nem is oly rég a VIA egyszerű és egyben vitatható ötlettel állt 
elő: válasszunk ki néhány kriptográfiai algoritmust, majd dró- 
tozzuk be őket a processzorba. Létrejött tehát egy i686 osztá- 
lyú processzor, amely néhány új, kifejezetten titkosítási célt 
szolgáló utasítást is képes megérteni. A technológia a VIA 
PadLock nevet kapta, míg maga a processzor teljes mértékben 
kompatibilis az AMD Athlon és az Intel Pentium lapkákkal. 

A rendelkezésre álló PadLock szolgáltatások körét a gép 
processzorának változata határozza meg. A processzorvál- 
tozatokat általában család-modell-fokozat hármassal jelölik. 
Az 1686 osztályú processzorok mindegyike a 6-os családba 
tartozik. Ha a modellszám 9-es, akkor a processzor 
Nehemiah, ha 10-es, akkor pedig Esther maggal rendelkezik. 
A fokozatok az egyes modellek megújított változatai. A pro- 
cesszor változatát a /proc/cpuinfo fájlban találjuk meg. 

A Nehemiah 3-as fokozata, illetve az újabb példányok elekt- 
romos zaj alapú véletlenszám-előállítóval (random number 
generator, RNG) rendelkeznek, ami meglehetősen jó vélet- 
len értékeket képes előállítani különféle célokra. Az RNG 
elérésére az xstore parancs szolgál. Az Intel és az AMD 
processzorokhoz hasonlóan a VIA processzorok véletlen- 
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szám-előállítóját is a hw random illesztőprogram támogatja. 
A Nehemiah 8-as és újabb fokozatai már két független RNG-t 
tartalmaznak, valamint az Advanced Cryptography Engine-nel 
(speciális kriptográfiai motor, ACE) bővültek. Az ACE az 
Advanced Encryption Standard (speciális titkosítási szabvány, 
AES) algoritmus alkalmazásával, háromféle szabványos kulcs- 
hosszal — 128, 192 és 256 bit — négyféle módban képes adato- 
kat titkosítani és visszafejteni. Az üzemmódok a következők: 
e — Elektronikus kódkönyv (electronic codebook, ECB) 

e Titkosítási blokkláncolás (cipher block chaining, CBC) 

e Titkosítási visszacsatolás (cipher feedback, CFB) 

e — Kimeneti visszacsatolás (output feedback, OFB) 


Az ezeknek megfelelő utasítások az xcryptecb, az 
xcryptcbc stb. A továbbiakban ezeket közös névvel 
xcrypt-nek fogom nevezni, az egyes módokhoz tartozó 
parancsokat nem fogom használni. 

Az Esther mag 0-s és újabb fokozatai örökölték a Nehemiah 
két RNG egységét. Az ACE kibővült a számláló (counter, CTR) 
mód támogatásával, valamint az izenethitelesítő kódok 
(Message Authentication Code, MAC) számításának lehetősé- 
gével. Itt két újabb rövidítéssel kellett megismerkednünk, 
ezek a PHE és a PMM. A PadLock Hash Engine (PadLock ki- 
vonatoló motor, PHE) adott bemeneti blokk kriptográfiai célú 
kivonatának elkészítésére alkalmas; az SHA1 vagy az SHA256 
algoritmussal dolgozik. Az ide kötődő parancs az xsha. 

A PadLock Montgomery Mutltiplier (PMM, PadLock 
Montgomery szorzó) az aszimmetrikus, más szóval nyilvá- 
nos kulcsú titkosítási eljárások során a legszélesebb körben 
használt parancsok egyikének felgyorsítását szolgálja; ez az 
A" mod M, ahol az A, a B és az M hatalmas nagy, általában 
1024 vagy 2048 biten ábrázolható szám. Szolgáltatásait 

a montmul utasítással vehetjük igénybe. 

Mint már utaltam rá, a továbbiakban leginkább az xcrypt uta- 
sításokról lesz szó. Az ismertetésre kerülő alapelvek túlnyomó 
részt a többi egységre is érvényesek, és az xcrypt csupán pél- 
daként szolgál. Sőt, a titkosítás kapcsán említett kifejezések 
és fogalmak a visszafejtés területén is megőrzik érvényüket. 


A PadLock használata 

A külső, általában a PCI buszra csatlakozó kriptográfiai gyor- 
sítókkal ellentétben a PadLock motor a processzor beépített 
része. Ennek köszönhetően jóval egyszerűbb a használata, 











1. táblázat Az OpenSSL teljesítményteszt eredménye 17,2 GHZ-es órajelű 


VIA Nehemiah processzoron [kBps/ 


aes-128-ecb (szoftveres)  11274,53  14327,79 14608,64 14672,55 

aes-128-ecb (PadLock) 66892,82  346583,52 910704,21 

aes-128-cbc (szoftveres)  — 8276,27 12915,75 13264. 13 13918/02 

aes-128-cbc (PadLock) 48542.30 241898,79 523706.28 745157,61 


hiszen nem kell a busz elérésével vagy éppen a megszakítá- 
sok és az aszinkron műveletek lekezelésével foglalkozni. 
Egy-egy memóriablokkot titkosítani egy xcrypt utasítással 
ugyanolyan egyszerű, mint átmásolni a movs utasítással. 
Ezen a szinten a titkosítás majdnem oszthatatlan művelet. Az 
utasítás végrehajtása előtt a puffer a nyílt adatokat tartalmaz- 
za, néhány órajellel később, az utasítás végrehajtásának befe- 
jezése után pedig már a titkosítottakat. Ha a kért művelet 
egyetlen blokk feldolgozása, ami az AES algoritmus esetében 
16 bájtot jelent, akkor a művelet teljesen oszthatatlan. Vagyis, 
a processzor nem szakítja meg a műveletet, és semmi másba 
nem kezd bele, amíg a titkosítással nem végzett. De mi törté- 
nik, ha a puffer több gigabájtnyi titkosítandó adatot tartal- 
maz? Nem volna túl jó ötlet minden más műveletet leállítani 
a hosszan tartó titkosítás befejezéséig. Ilyenkor a processzor 
minden egyes 16 bájtos blokk után jogosult megszakítani 

a titkosítást. Elmenti a pillanatnyi állapotot, majd elvégzi 

a rá várakozó feladatokat, mint a megszakítások kezelése 
vagy az egyéb folyamatok futtatása. A titkosítási folyamat 
újraindításakor az utasítás elvégzése attól a ponttól folytató- 
dik, ahol felfüggesztésre került. Ez az, amiért csak majdnem 
oszthatatlan a művelet: a hívó folyamat számára annak lát- 
szik, ám nagyobb fontosságú esemény megszakíthatja. 

A pillanatnyi feldolgozási állapot és a futó folyamat regiszte- 
rei elmentésre kerülnek a memóriába, vagyis egyszerre több 
folyamat is végezhet titkosítást, nem kell adataik összekeve- 
redésétől tartani. Ismétlem, mindez sokban hasonlít a me- 
móriablokkoknak a movs utasítással végzett másolására. 


Mennyire gyors? 

A VIA adatai szerint egy 1.2 GHz órajelű processzor maxi- 
mális átviteli sebessége több mint 15 Gbps, vagyis majdnem 
19 GBps. Az általam végzett teljesítnménymérések igazolták, 
hogy valós alkalmazásoknál is láthatunk hasonló sebessége- 
ket, nemcsak a VIA marketinganyagaiban, ami rendkívül 
kellemes meglepetés volt. 

A tényleges titkosítási sebesség két tényezőtől függ, a titko- 
sítási módtól és az adatok igazításától. Az ECB a leggyor- 
sabb, a legszélesebb körben használt CBC pedig nagyjából 
az ECB sebességének felét képes hozni. A PadLock megkö- 
veteli az adatok 16 bájtos határokra igazítását, ezért az iga- 
zítás nélküli adatokat először a megfelelő címekre kell moz- 
gatni, ami némi időveszteséget okoz. Egyes esetekben az 
Esther processzorok képesek az adatok önműködő igazítá- 
sára is, ám a sebességcsökkenés ekkor is fellép. 

Az 1. táblázat méréseim eredményeinek egy részét tartal- 
mazza. Az eredményeket az OpenSSL teljesítményteszttel, 
1,2 GHz-es VIA Nehemiah processzoron kaptam, a mennyi- 
ségek mértékegysége kBps. 
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Minél nagyobbak a blokkok, annál jobbak az 
eredmények, ugyanis eltűnnek az OpenSSL 
könyvtár által okozott többletterhelések. A 8 
kB-os blokkok ECB módban végzett titkosítá- 
sa körülbelül 1,7 GBps sebességgel lehetséges, 
míg CBC módban 800 MBps-ot kapunk. 

A szoftveres titkosítással összehasonlítva 

a PadLock ECB módban ugyanazon a pro- 
cesszoron 120-szor gyorsabb, míg a CBC mód 
esetében 60-szoros az eltérés. 

A gyorsulásnak köszönhetően az IPsec 100 
Mbps sebességű hálózaton teljes értékűen, nagyjából 11 
MBDPps sebességgel működik. A titkosított fájlrendszerek 
esetében hasonló sebességjavulásokat lehet tapasztalni. 

A Bonnie teljesítménytesztet egy UDMA100 módban üze- 
melő Seagate Barracuda merevlemezzel futtatva, nyílt ada- 
tokkal 61543 kBps-os átviteli sebességet kapunk. PadLockot 
használva ez 49961 kBps-ra mérséklődik, míg tisztán szoft- 
veres titkosítás használatakor csupán 10005 kBps-ot lehet 
elérni. A PadLock alkalmazásakor tehát a titkosítatlan átvi- 
telhez képest csupán 20 százalékos teljesítménycsökkenés- 
sel kell számolni, míg a szoftveres megoldásnál ez közel 85 
százalék. A források között szerepel egy a teljesítménymé- 


14693,72 


(18822.92 
846402,90 


rések eredményeit tartalmazó oldalamra mutató hivatko- 
zás; ott további részletek és számok is megtalálhatók. 


Linux alatti támogatás 

A linuxos támogatást eddig - az alábbi csomagokhoz -— csak 
az xcrypt utasítás révén használható AES algoritmushoz 
készítettem el, Esther magos processzorhoz ugyanis még 
nem jutottam hozzá. Amint megkapom az új processzor 
egy példányát, szükség szerint meg fogom oldani a többi 
algoritmus támogatását is. 


Rendszermag 

Ha a rendszermagnak szüksége van az AES algoritmusra, 
akkor alapesetben az aes . ko modult tölti be, amely az algo- 
ritmus szoftveres megvalósítása. Ha az AES-t a PadLockkal 
akarjuk futtatni, akkor az aes .ko helyett a padlock.ko 
modult kell betöltenünk. Ezt kézzel, a modprobe paranccsal 
tehetjük meg, illetve az alábbi sort hozzáadva a /etc/ 
modprobe.conf fájlhoz: 

alias aes padlock 


Ezt követően minden alkalommal, amikor AES-re lesz szük- 
sége, a rendszermag a padlock.ko modult is betölti. 

Foltok a rendszermag 2.6.5-ös és újabb változataihoz létez- 
nek; lásd a források közötti linuxos PadLock oldalt. Az alap- 
szintű illesztőprogram a 2.6.11-es rendszermag alapváltoza- 
tában, mindenféle foltozás nélkül is elérhető lesz. 


OpenSSL 

Azok, akik elég merészek ahhoz, hogy az OpenSSL újabb, CVS 
alatti változatait használják, már rendelkeznek a PadLock tá- 
mogatásával. Az OpenSSL 0.9.7-es változatát futtatóknak meg 
kell foltozniuk és újra kell fordítaniuk a könyvtárat; illetve le- 
hetséges, hogy terjesztésük csomagjai már eleve tartalmazzák 
a foltot, ilyen terjesztés például a SuSE Linux 9.2. Azt, hogy 
saját OpenSSL példányunk rendelkezik-e PadLock támoga- 
tással, az alábbi egyszerű paranccsal vizsgálhatjuk meg: 
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$ openss] engine padlock 
(padlock) VIA PadLock (RNG, ACE) 


Az (RNG, ACE) helyett lehet, hogy (no-RNG, no-ACE) jelenik 
meg, ez azt jelenti, hogy bár OpenSSL-ünk képes a PadLock tá- 
mogatására, gépünk processzora nem nyújt ilyen szolgáltatást. 
Lehet, hogy csúf hibaüzenet jelzi, hogy nincs ilyen motor 

a gépünkön, ekkor el kell végeznünk az OpenSSL könyvtár 
frissítését vagy foltozását. A titkosítási műveleteik végrehaj- 
tására az OpenSSL-t használó programoknak a PadLock támo- 
gatás használatához az úgynevezett EVP. interface-t kell hasz- 
nálniuk, valamint valamikor futásuk elején el kell végezniük 

a hardveres gyorsító kezdeti értékadását: 

finclude copenssl/engine.h: 

int main 0 


í 
[6551] 
ENGINE load builtin enginesO; 
ENGINE. register all completeO; 
Lsd 

3 


További részletek az OpenSSL leírásának evp(3) man oldalán 
találhatók. Például SuSE Linux 9.2 alatt az OpenSSH-nak 
van egy hasonló foltja, amivel gyorsabb hálózati scp- 
átviteleket lehet végezni. 


Binutils 

Ha a PadLockot saját programjainkban akarjuk használni, 
akkor a megfelelő utasítást név szerint is meghívhatjuk 

— mint például xcryptcbc —, de hexadecimális formában, 
közvetlenül is írhatjuk: 

.byte Oxf3,0XxOf, 0xa7 , 0xdO 


A régebbi fejlesztőeszközökkel való együttműködés biztosí- 
tása érdekében inkább a műveleti kódos formátumot hasz- 
náljuk. A Binutils 2.15-ös és újabb változatai ugyanakkor, 
ahol kell - ilyen például a gas (GNU assembler) és az 
objdump -, ott ismerik a szimbolikus neveket is. A binutils 
többek közt az utasításszintű műveletekért felelős BED 
könyvtárát használja a GNU gdb hibakereső is. Egy titkosító 
függvény kiíratása például így nézhet ki: 

(gdb) x/3i $pc 
0x8048392 cdemolt14:: 
0x8048398 cdemolt205: 
0x804839c cdemolt24:: 


1ea 0x80495f0,7edx 
repz xcryptecb 


push 7eax 


Mint sejteni lehetett, a SLISE Linux 9.2 minden vonatkozó 
csomagja rendelkezik PadLock foltokkal, így a PadLock tá- 
mogatás ennél a terjesztésnél már gyári állapotban is meg- 
oldott. Akinek a terjesztése nem rendelkezik a foltokkal, az 
látogasson el a források között szereplő Linux PadLock hon- 
lapomra, és keresse meg a számára szükségeseket. 


A PadLock programozása 

Az alábbiakban néhány a PadLock programozásával kapcsola- 
tos irányelvet szeretnék ismertetni, és kicsit részletesebben is 
foglalkozni fogok az xcryptcbc-vel. Példát mutatok a PadLock 
alkalmazására egy adatpuffer AES algoritmussal, 128 bites 
kulccsal, CBC módban végzett titkosítására. Az xcrypt csoport 
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összes többi utasítása is pontosan így használható, illetve az 
egyéb PadLock-szolgáltatások is hasonlóan működnek. 


xeryptcbe 

Az xcryptcbc semmilyen explicit operandussal nem 
rendelkezik. Ehelyett minden regiszternek meghatározott 
szerepet ad: 

e  ESI- forráscím. 

e  EDI- célcím. 

e —EAX — kezdeti értékadási vektorcím. 

e  EBX- titkosító kulcs címe. 

e — ECX- a feldolgozandó blokkok száma. 

e  EDX - vezérlőszó címe. 


Alapesetben minden címet 16 bájtos határra kell igazítani. 


ESI/EDI — A forrás- és céladatok címei 

A forrás- és a célcím akár azonos is lehet, vagyis a titkosítást 
helyben is végezhetjük. A célpuffernek legalább akkorának 
kell lennie, mint a forrásnak. Mindkettő méretének a blokk- 
méret (16 bájt) többszörösének kell lennie. Egyes esetekben 
az Esther processzor az igazítás nélküli pufferek használatát 
is lehetővé teszi, de ilyenkor a művelet végrehajtása lassabb. 


EAX — kezdeti értékadási vektorcím 

A kezdeti értékadási vektor (initialization vector, IV) egyike 
a titkosítás eredményét meghatározó átadott értékeknek. 
Az IV mérete megegyezik a blokkmérettel, vagyis 16 bájt. 

A kezdeti értékadási vektorokról a megfelelő szakirodalom- 
ban lehet részletesebben olvasni. 


EBX — titkosító kulcs címe 

A titkosító kulcs mérete 128, 192 vagy 256 bit lehet. Az AES 
algoritmus belül úgynevezett kiterjesztett kulcsot használ, 
amit a titkosító kulcsból származtat. A 128 bites kulcsoknál 
a kiterjesztett kulcsot a PadLock számítja, a hosszabb kul- 
csoknál ezt nekünk kell megtennünk. 


ECX — feldolgozandó blokkok száma 

Az xcrypt utasításokat mindig a rep előtaggal használjuk, 
ami lehetővé teszi ismételt végrehajtásukat egészen addig, 
amíg az ECX regiszter értéke nulla nem lesz. Az Ecx által 
tárolt érték az egyes blokkok titkosításakor vagy visszafej- 
tésekor fokozatosan csökken. 


EDX — vezérlőszó címe 

A PadLock csak akkor tudja, hogy pontosan hogyan kell 

feldolgoznia az adatokat, ha az úgynevezett vezérlőszó 

adatszerkezetet feltöltjük a következő elemekkel: 

e Algoritmus (a1go) — csak az AES-t választhatjuk. 

e — Kulcsméret (ksize) — a támogatott méretek egyike. 

e Irány (encdec) - titkosítás vagy visszafejtés. 

e  Kulcselőállítás (keygen) — elkészítettük a kiterjesztett 
kulcsot, vagy a PadLocknak kell kiszámítania? 

e — Körök (rounds) - az algoritmus egyik belső értéke, je- 
lentését lásd a későbbiekben vagy a PadLock leírásában. 


C-ben egy union tökéletesen megfelel az adatszerkezet he- 
lyének lefoglalására, elemeit pedig egy bitmező segítségével 
könnyen meg tudjuk adni és el tudjuk érni: 








union cword f 
uint8 t cword[16]; 
struct ( 

int 
int 


rounds:4; 
algo:3; 

keygen:1; 
interm:1; 


int 
int 
int 
int 


3 b; 


encdec:1; 
ksize:2; 


3; 
Assembler példa 


Elméletből mindent tudunk, nézzünk egy valódi példát. 
Kezdjünk néhány tiszta assembler-sorral: 


. comm iv,16,16 

. comm key,16,16 

. comm data,16,16 

. comm cword,16,16 

. text 

cryptcbc: 
mov1 $data, Zesi $; forráscím 
mov1 J7esi, 97edi ft; cél 
mov1 $iv, 9eax $; IV 
mov1 $key, Xebx tt; titkosító kulcs 
mov1 $cword, 9edx $; vezérlőszó 
mov1 $1, 9ecx tt; blokkszám 
rep xcryptcbc 
ret 


A fenti kódrészlet megadott titkosító kulccsal és kezdeti ér- 
tékadási vektorral, a cword vezérlőszóban megadottak sze- 
rint titkosít egy adatblokkot. Megjegyzem, hogy mivel hely- 
ben titkosítunk, a forrás- és a célcím azonos. Mivel a data 
mező mérete egyetlen blokknyi, az Ecx regiszter értékeként 
egyet adtunk meg. 


C példa 
Ha a PadLockot közvetlenül, C programból akarjuk hasz- 
nálni, akkor megtehetjük például, hogy a PadLock eljáráso- 
kat külön assembler forrásfájlokba helyezzük, majd a fordí- 
tást különálló modulokba végezzük, végül összekapcsoljuk 
a bináris fájt. Egyszerűbb azonban a GCC beépített assemb- 
lerét használni, és az utasításokat közvetlenül a C kódba 
illeszteni. A források között szerepel egy a beépített 
assemblerrel kapcsolatos oktatóanyagra mutató hivatkozás. 
static inline void " 
padlock xcryptcbcCchar "input, char "output, 

void "key, void "iv, void "control word, 

int count) 


í 
asm volatile ("xcryptcbc" 
"45"(Cinput), "4D"(output), "4a"Civ) 
"c" (count), "d"(control word), 
5 "b"(key)); 
return iv; 
3 


A fenti kódrészlet a fordítót a megfelelő bemeneti, számláló 
és egyéb átadott értékek megfelelő regiszterekbe való betöl- 


www.linuxvilag.hu 


tésére utasítja. Ezután sor kerül az xcryptcbc utasítás kiadá- 
sára, majd az EAX regiszterben talált értékkel térünk vissza, 
mint az új kezdeti értékadási vektorra irányuló mutatóval. 
Ügyeljünk a vezérlőszó adatszerkezet helyes kitöltésére. 

A legjobb az, ha első lépésként töröljük az union-t, így elke- 
rülhetjük a memóriában esetlegesen előforduló értékek 
használatát: 

memset(€cword, 0, sizeof(cword)); 


Most egyenként töltsük fel a mezőket. A lista első eleme 

a rounds. Ez adja meg, hogy az AES algoritmus hányszor 
menjen végig a bemeneti blokkon. Az algoritmus minden 
körben a kiterjesztett kulcs egy egyedi részét használja. 

Ha a FIPS AES szabványát akarjuk követni, akkor 128 bites 
kulcsnál 10, 192 bitesnél 12, 256 bitesnél pedig 14 kört kér- 
jünk. Ha a key. size változó a titkosító kulcs méretét bájtban 
adná meg, akkor a körök számát az alábbi képlettel kapnánk: 
cword.b.rounds - 10 4 (key size - 16) / 4; 


A következő mező az algo. Segítségével a későbbiekben 
más, az AES-től eltérő algoritmusokat is választhatunk 
majd, ám jelenleg kizárólag az AES áll rendelkezésünkre. 
Értékét tehát hagyjuk nullán. 

A keygen mezőt akkor állítsuk egyre, ha a kiterjesztett 
kulcsot magunk állítjuk elő. A nullás érték azt jelenti, hogy 
a PadLocknak magának kell azt előállítania; erre viszont 
csak 128 bites kulcsnál van lehetőség: 

cword.b.keygen - (key size : 16); 


Az interm lehetővé teszi az algoritmus futtatásának egyes 
körei után kapott köztes értékek tárolását. Van egy olyan 
gyanúm, hogy a processzor tervezői ezt a mezőt a pro- 
cesszormag hibáinak felderítésére használták, alkalmazáso- 
kon belüli használatának nem látom értelmét. 

A titkosítás és a visszafejtés megkülönböztetése az encdec 
bittel történik. A nulla titkosítást, az egy visszafejtést jelent. 
Végül a kulcsméretet a ksize két bittel adja meg: 
cword.b.ksize - (key size - 16) / 8; 


Ennyi. A vezérlőszó előkészítése és a pufferek igazítása 
után meghívhatjuk a padlock xcryptcbcO-t. Ha a gépben 
keringő elektronok is úgy akarják, néhány pillanat múlva 
megkapjuk a titkosított adatokat. 


Osszefoglalás 

A PadLock leírása nyilvánosan elérhető a VIA webhelyén, 
ahol további a PadLock programozásával kapcsolatos 
anyagokat is találni. Saját honlapomon szerepel egy teljes, 
a PadLock segítségével egyetlen adatblokkot titkosító pél- 
daprogram. A források között további figyelemre érdemes 
hivatkozások is szerepelnek. 
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WLAN-ok védelme WPA és FreeRADIUS 


alkalmazásával - III. rész 


Új, a korábbiaknál biztonságosabb vezeték nélküli hálózatunk üzembe 
helyezésének végső lépéseként fel kell készítenünk néhány nem linuxos 


ügyfelet az új szabvány kezelésére. 


lőző két írásomban áttekintettem, hogy a WPA 
a (Wi-Fi protected access, Wi-Fi védett elérés) segítsé- 

gével hogyan védhetjük meg a vezeték nélküli 
(wireless) helyi hálózatokat, röviden WLAN-okat a jogo- 
sulatlan hozzáférésektől és a lehallgatásoktól. Elkezdtem 
ismertetni, hogy a FreeRADIUS segítségével hogyan való- 
síthatjuk meg a WPA-t saját WLAN-unkon. Az eddigiek 
során a FreeRADIUS telepítéséről, a hitelesítő szervezet 
(certificate authority, CA) létrehozásáról, valamint 
a WPA-val történő használatra szánt digitális tanúsít- 
ványok előállításáról és aláírásáról volt szó. Ebben a hó- 
napban megnézzük, hogy hova kell elhelyezni ezeket 
a tanúsítványokat, hogyan kell beállítani a FreeRADIUS-t, 
a vezeték nélküli hozzáférési pontot és az ügyfeleket. 
Mindezek alapján, úgy vélem, bárki nekiláthat saját 
WLAN-ja biztonságának megerősítéséhez. 


Rövid ismétlés 

Azok számára, akik csak most kapcsolódnak be a cikk- 
sorozatba, esetleg fel kell frissíteniük az emlékezetüket, 
hogy pontosan mit is próbálunk elérni, röviden tekint- 
sük át céljainkat és lehetőségeinket. A WPA erőteljes 
hitelesítési eljárásokkal bővíti a régebbi, kriptográfiailag 
megtört WEP protokollt; teszi ezt a 802.1x protokoll és 
alprotokolljai révén, mint az EAP, a PEAP és az EAP-TLS. 
A WPA a TKIP protokoll révén képes a munkamenetkul- 
csok dinamikus egyeztetésére és a kulcsok önműködő 
megújítására is. Ha vezeték nélküli ügyfelünk támogatja 
a WPA-t — vagyis rendelkezik WPA kérvényezővel -, 
továbbá a vezeték nélküli hozzáférési pontunk is rendel- 
kezik ilyen képességgel, akkor kétharmad részben már 
sikerrel jártunk. Ha viszont teljes mértékben ki akarjuk 
használni a 802.1x által kínált lehetőségeket, akkor szük- 
ségünk lesz egy RADIUS háttérkiszolgálóra is — itt lép 
be a képbe a FreeRADIUS. 

A múlt alkalommal kialakított példakörnyezetben egy 
FreeRADIUS kiszolgálót helyezünk üzembe, amelynek fel- 
adatául a tetszőleges WPA-képes vezeték nélküli hozzáféré- 
si ponthoz csatlakozó Windows XP ügyfelek hitelesítését 
tűztük ki. 802.1x eljárásunk az EAP-TLS lett. Az EAP-TLS, 
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mint talán néhányan még emlékeznek rá, a TLS protokollt 
használja a vezeték nélküli kérvényezők (ügyfelek) és 

a hozzáférési pontok kölcsönös hitelesítésére; illetve mind- 
ehhez X.509 digitális tanúsítványokat alkalmaz. 

Még hátralévő feladataink a következők: 


e A múlt alkalommal létrehozott kiszolgáló és CA 
tanúsítványok telepítése a FreeRADIUS kiszolgálóra 


e A FreeRADIUS beállítása ezeknek a tanúsítványoknak 
a használatára, EAP-TLS felett, a hozzáférési pont 
felhasználóinak hitelesítése céljából 


e A hozzáférési pont beállítása a hitelesítés átirányítására 
a FreeRADIUS kiszolgálóra 


e Az ügyfélprogram és a múlt alkalommal létrehozott 
CA tanúsítványok telepítése egy Windows XP alapú 
ügyfélre, illetve beállítása úgy, hogy a WLAN-hoz 
történő csatlakozáskor WPA-t használjon. 


A FreeRADIUS kiszolgáló előkészítése 

A WPA-ról szóló sorozat második részében létrehoztunk 
három X.509 digitális tanúsítványt: a hitelesítő szervezetét 
(cacert.pem), egy kiszolgálótanúsítványt 

(kiszolgalo kulcstanusitvany.pem) és egy ügyféltanúsítványt 
(ugyfel tanusitvany.p12). A kiszolgáló és az ügyfél fájlja 

a tanúsítványt és annak titkos kulcsát egyaránt tartalmazza, 
ezért mindkettő telepítését kellő körültekintéssel kell elvé- 
gezni. A CA tanúsítványt ugyanakkor a kulcstól elkülönítve 
tároljuk, vagyis a cacert.pem-et szabadon terjeszthetjük. 

A FreeRADIUS beállító fájljai a /etc/raddb/ vagy 

a /usr/local/etc/raddb/ könyvtárban találhatók, terjesztéstől 
függően. A könyvtárnak van egy certs/ nevű alkönyvtára, 
ide kell bemásolnunk a CA tanúsítványát, valamint 

a kiszolgálótanúsítványt és kulcsát. Ellenőrizzük, hogy 

a cacert.pem tulajdonosa a root felhasználó-e, a fájlra 
vonatkozó engedélyek pedig a következők legyenek: 


-r--r--r-- 











1. kódrészlet A raddb/certs könyvtárban található 
tanúsítványokra megadott tulajdonosok és engedélyek 


-r--r--r-- 1 root users 1294 2005-02-10 01:05 
5 cacert.pem 
-r---— 1 nobody users 1894 2005-02-10 01:00 


s kiszolgalo kulcstanusitvany.pem 


2. kódrészlet A radiusd.conf két 
módosítandó beállítása 


user - nobody 
group - nobody 


A kiszolgalo kulcstanusitvany.pem fájlnak ugyanakkor 

a nobody felhasználó tulajdonába kell tartoznia, -r-—------ 
engedéllyel. Az 1. kódrészlet ennek a két fájlnak a hosszú 
könyvtárlistáját szemlélteti. 

Ha már a fájlok tulajdonosaival foglalkozunk, ellenőrizzük, 
hogy a /var/log/radius/radius.log fájlra és a /var/run/radiusd/ 
könyvtárra van-e írási engedélye a nobody felhasználónak. 
Ha a FreeRADIUS-t forrásból fordítottuk, akkor lehetséges, 
hogy az előbbiek helyett a /usr/local/var/log/radius/ 
radius.log fájllal és a /usr/local/var/srun/radiusd/ könyvtár- 
ral kell dolgoznunk. A radius.log és a radiusd/ tulajdonosa 
egyaránt a nobody legyen. 

Mielőtt beleásnánk magunkat a FreeRADIUS beállító fájljai- 
ba, létre kell hoznunk további két, a FreeRADIUS által a TLS 
használatához igényelt fájlt. Az első a Diffie-Hellman (dh) 
átadott értékeket tartalmazza, ezekre a TLS munkamenet- 
kulcsok egyeztetésekor van szükség. A dh fájlt úgy hozhat- 
juk létre, hogy átváltunk a FreeRADIUS raddb/[certs/ könyv- 
tárába, majd kiadjuk a következő parancsot: 


ff openss] dhparam -check -text -5 512 -out dh 


A második fájl egy véletlenszerű bitfolyamot tartalmazó, szin- 
tén a TLS műveleteknél szükséges adatfájl, random névvel. 

Itt hívnám fel rá a figyelmet, hogy a véletlenszerűnek szánt 
tartalmak létrehozását nem szabad egyszerűen az aktuális idő- 
bélyeg vagy valamilyen hasonló, a legkevésbé sem véletlen- 
szerű karakterlánc beírásával letudni; még akkor sem, ha 

a WPA-val kapcsolatos, az interneten fellelhető leírások né- 
melyikében ezt javasolják. Ehelyett a rendszermag kiváló mi- 
nőségű véletlenszám-előállítóját kell használni. A raddb/certs 
könyvtárból tehát a következő parancsot adjuk ki: 


4 dd if-/dev/urandom of-random count-2 


Mindkét fájlra olvasási jogot kell adni a nobody felhasználó- 
nak, az írási jogot pedig mindenkitől meg kell vonni. 


A FreeRADIUS beállítása 
Végre készen állunk a FreeRADIUS beállításainak megadá- 
sára. Elég ijesztő lehet a /raddb könyvtárban sorakozó fájlok 
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sokasága, de riadalomra semmi ok. Az EAP-TLS alapú WPA 
használatához csak a következő három fájlt kell módosíta- 
nunk: radiusd.conf, eap.conf és clients.conf. 

A radiusd.conf fájlban csupán azt kell megadnunk, hogy 

a radiusd folyamat melyik felhasználó és csoport jogaival fus- 
son. A jogok alapesetben a démont indító felhasználótól 
öröklődnek. Ha a radiusd-t parancsfájlból indítjuk, akkor 

a root jogait örökli — nyilván ezt el szeretnénk kerül. Felhasz- 
nálóként és csoportként tehát a radiusd.conf-ban egyaránt 
nobody-t adjunk meg, ahogy ezt a 2. kódrészlet is szemlélteti. 
Természetesen a nobody/nobody helyett más, kiemelt jogokkal 
nem rendelkező felhasználót és csoportot is választhatunk, 
ám ha így teszünk, akkor a korábban említett tanúsítványfáj- 
lok tulajdonosait és a vonatkozó jogokat is módosítanunk 
kell. Bárhogy is döntünk, ellenőrizzük, hogy a kiválasztott fel- 
használóhoz a /etc/password fájlban tartozó bejegyzés szerint 
a felhasználó nem kaphat héjhozzátférést (a bejegyzés például 
/bin/false vagy /bin/true lehet); a fiókot SSH, telnet és hasonló 
programok nem használhatják. Mondanom sem kell, azt sem 
árt ellenőrizni, hogy a felhasználó és a csoport egyáltalán léte- 
zik-e, és ha nem, létre kell hozni őket. 

A radiusd.conf további beállításokat is tartalmaz, ám csak 

a fenti kettő módosítása az, ami igazán lényeges. További 
tudnivalókat a radiusd.conf(5) man oldalon vagy Jonathan 
Hassell RADIUS című könyvében találni. 

A következő átírandó fájl az eap.conf — itt merülünk a sűrűjé- 
be. A 3. kódrészlet az eap.conf módosítandó sorait tartalmazza. 
A 3. kódrészletben a private key password átadott érték- 
kel megadtam egy kiszolgáló-kulcs jelszót. Ez valójában 
üres, feltéve, hogy a kiszolgáló tanúsítványát és kulcsát az 
OpenSSL -nodes kapcsolójával hoztuk létre. Sajnos a múlt 
hónapban magam is ezt javasoltam, ám most, talán még 
időben, szeretném ezt visszavonni. A jelszó nélküli X.509 
kulcsok használata ront a biztonságon, még ha a kulcsot 
nyílt szöveges beállító fájlban tároljuk is, mint például az 
eap.conf. Bizony, ha a FreeRADIUS kiszolgálón egy behatoló 
root jogokhoz jut, akkor — köszönhetően az eap.conf fájl- 
nak — még egy jelszóval védett tanúsítvány bizalmassága 

is sérülhet. Ha viszont a tanúsítványt/kulcsot út közben 

— például, amikor a CA állomásról a FreeRADIUS kiszol- 
gálóra másoljuk — hallgatják le, akkor, ha jelszóval védett, 

a támadó nem tud mit kezdeni vele. 

Bármelyik megoldást is válasszuk, ellenőrizzük, hogy az 
eap.conf a root tulajdonában van-e, illetve csak ő rendelke- 
zik-e hozzá írási joggal, és nem a radiusd.conf fájlban meg- 
adott felhasználó. Furcsa, igaz? A nobody-nak nem kellene 
jogot adni a beállító fájlok olvasására? A válasz nem, hiszen 
ha a radiusd-t rootként indítjuk, akkor először beolvassa 

a beállító fájlokat (radiusd.conf, eap.conf és clients.conf), 
csak ezután vált át a nobody jogosultságaira. 

Végül létre kell hoznunk egy bejegyzést a hozzáférési pont 
számára a clients.conf fájlban. A 4. kódrészlet erre mutat 
példát. 

A 4. kódrészletben a client (ügyfél) utasítás adja meg 

a hozzáférési pont IP-címét. A hozzá tartozó secret (titok) 
átadott érték adja meg azt a karakterláncot, amelyet a hoz- 
záférési pont a FeeRADIUS kiszolgálónak küldött kérések- 
ben titkosítási kulcsként használ. A shortname (rövid név) 
egyszerűen csak egy álnév a hozzáférési ponthoz, például 
a naplóbejegyzésekben találkozhatunk vele. 
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3. kódrészlet Az eap.conf fájl módosításai 


eap í 
f Itt számos általános EAP átadott érték 
ft megadására van lehetőség, 
tt ám számunkra most csak 
$ a default eap type fontos: 
default eap type — tls 
ft Ezután következnek az egyes 
í EAP-típusok beállításai. 
ft Mivel EAP-TLS-t akarunk használni, 
ft csak a tlsí3 szakasszal 
ft kell foglalkoznunk: 
GUS 1 
tt Az alábbi értékek azt adják meg 
ft a radiusd-nek, hogy hol 
ft találja a tanúsítványokat és a kulcsokat, 
ft illetve a dh és a random fájlokat: 
private key password -— 
Side jon a kulcs jelszava 
private key file — 
5 $(raddbdirl/certs/bt. keycert.pem 
certificate file - 
5 $(raddbdirl/certs/bt keycert.pem 
cA file - $íraddbdirl/certs/cacert.pem 
dh file - $í(raddbdirj/certs/dh 
random file - $íraddbdirj/certs/random 
ih 


4. kódrészlet Hozzáférési ponthoz tartozó bejegyzés 
a clients.conf fájlban 


eljent-10-1.2- 37/3288 
secret 
shortname 


- felhasznalojelszo 
- hozzaferesi pont 


A radiusd készen áll az indításra, amit az rc.radiusd 
parancsfájllal tehetünk meg: 


rc.radiusd start 


Az újraindítás az rc.radiusd restart paranccsal történik. 


Ha a radiusd hiba nélkül elindult, továbbléphetünk. 


A hozzáférési pont beállítása 
A következő lépés az egész folyamat legkönnyebb része: 


hozzáférés biztosítására is képes Actiontec DSL forgalomirá- 
nyító. Ennek webes felületén a SetuppAdvanced Setup:Wireless 
Settings (Beállítások Speciális beállítások Vezeték nélküli beál- 
lítások) pontra kattintottam, majd a Security (Biztonság) beál- 
lításnál a WPA-t választottam. Ezután előre megosztott kulcs 
helyett átállítottam 802.1x használatára. Kellett adnom neki 
egy kiszolgálócímet, ez 10.1.2.3 lett, továbbá be kellett írnom 
a FreeRADIUS kiszolgáló IP-címét, valamint a 4. kódrészlet- 
ben már látott titkot (felhasznalojelszo). A kapuszámot az 
alapértelmezett 1812-n hagytam. 

Ha már szóba került a téma: ha a hozzáférési pontot és 

a RADIUS kiszolgálót tűzfal választja el egymástól, akkor 
lehetővé kell tennünk, hogy a hozzáférési pont elérhesse 

a RADIUS kiszolgáló 1812-es és 1813-as kapuját. Ekkor egy- 
ben a RADIUS kiszolgáló is módot kap válaszainak ezeken 
a kapukon keresztül történő továbbítására. 


A Windows XP alapú ügyfelek beállítása 

Végre elérkeztünk oda, hogy a Windows XP alapú, vezeték 
nélküli ügyfeleket beállíthassuk a WPA használatára képes- 
sé tett hozzáférési ponthoz való csatlakozásra. Tudom, hogy 
linuxos magazinba írok, ezért nem akarok túlságosan sokat 
rágódni a témán, akit részletesebben is érdekel, az olvassa 
el Ken Roser HOGYAN-jának 4.3-as szakaszát (lásd a forrá- 
sokat). Ieendőink röviden: 


1. Start,Futtatás (Start.Run), majd az mmc parancs futtatása. 


2. A Microsoft Management Console-ban válasszuk 
a FájbBeépülő modul hozzáadása/eltávolítása 
(File: Add/Remove Snap-in) parancsot, válasszuk ki 
a Tanúsítványok (Certificates) beépülő modult, majd 
válasszuk a saját fiókunkhoz tartozó tanúsítványok 
helyi gépre vonatkozó kezelését. 


3. Másoljuk át CA tanúsítványunkat (cacert.pem) 
a windowsos rendszer merevlemezére, például 
C:lcacert.pem névvel. 


4. Az MMC-ben bontsuk ki a Kezelőpultgyökér (Console 
Root) és a Tanúsítványok - Aktuális felhasználó 
(Certificates - Current LIser) csomópontot, majd kattint- 
sunk az egér jobb gombjával a Megbízható legfelső 
szintű hitelesítésszolgáltatók (TIrusted Root Certification 
Authorities) elemre. A helyi menüből válasszuk az 
Összes feladabImportálás (AII TaskssImport) parancsot. 
A varázslóban válasszuk ki a C:lcacert.pem fájlt, 
majd mentsük el a megbízható legfelső szintű 
hitelesítésszolgáltató alá. 


5. Másoljuk át az ügyfél tanúsítvány/kulcs fájlját 
a windowsos rendszerre, például 





a vezeték nélküli hozzáférési pont beállítása WPA használa- 
tára és a FeeRADIUS kiszolgáló címének megadása. Mind- 


ehhez csupán kétféle adatra van szükség, a FreeRADIUS 6. 


kiszolgáló clients.conf fájljában megadott RADIUS titokra 
(secret átadott érték), valamint a kiszolgáló IP-címére. 

Az, hogy ezeket az adatokat ténylegesen hogyan kell megad- 
ni a hozzáférési pontnak, az alkalmazott eszköztől és a rajta 
futó szoftvertől függ. Az én hozzáférési pontom egy WLAN- 
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CAugyfel tanusitvany.p12 névvel. 


A kezelőpulton kattintsunk az egér jobb gombjával 

a Tanúsítványok (Certificates) csomópont Személyes 
(Personal) ágára. A helyi menüből válasszuk az Összes 
feladatImportálás (All Taskss: Import) parancsot. 

A megjelenő varázslóban importáljuk be 

a C:ugyfel tanusitvany.p12 fájlt. 








7. Az importáló varázsló bekéri tőlünk a tanúsítvány jel- 
szavát, illetve ugyanezen a párbeszédpanelen felkínálja 
a titkos kulcs erőteljes védelmét is. Sajnos ennek az en- 
gedélyezése megakadályozza a WPA működését, vagyis 
a használatától el kell tekintenünk. A kulcs exportálását 
engedélyező négyzetet is hagyjuk érintetlenül, jobban 
járunk ugyanis, ha a jelszóval védett fájlról készítünk 
biztonsági mentést, mintha az importált, jelszóval nem 
védett változat exportálását engedélyeznénk. 


8. A következő képernyőn hagyjuk, hogy a varázsló magá- 
tól kiválassza a tanúsítványtárolót. 


Ezzel a Windows XP alapú rendszer készen áll, már csak 
egy vezeték nélküli hálózati profilt kell létrehoznunk. 
Ennek módja a vezeték nélküli kártya illesztőprogramjaitól 
és attól függően változik, hogy a Windows XP melyik szer- 
vizcsomagját telepítettük. Nálam Windows XP SP1 fut, 
Centrino lapkakészleten, és az XP saját WPA kérvényezőjé- 
vel hoztam létre vezeték nélküli hálózati profilt, megadva 
saját WLAN-om SSID-jét. Hálózati hitelesítésre (Network 
Authentication) WPA-t, adattitkosításra (Data encryption) 
TKIP-t választottam, az EAP típusa (EAP type) pedig intel- 
ligens kártya vagy más tanúsítvány (Smart Card or other 
Certificate) lett. A Windows magától felismerte, hogy 
milyen ügyféltanúsítványt akarok használni — ez annak 
köszönhető, hogy a múlt alkalommal külön lépésekkel 
gondoskodtunk arról, hogy az ügyféltanúsítványunk 
tartalmazza a Windows XP kiterjesztett jellemzőit. 


dn 
KEKEC ennek megvalósításáról a Ti szavazataltok sz 
Kén 2 oldalór 


válaszoljon néhány kérdésre ezen a. 


Megjelent! 
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Miután megtörtént a vezeték nélkül hálózati profil össze- 
állítása, a Windowsnak önműködően kapcsolódnia kell 

a hozzáférési ponthoz, és végre kell hajtania a WPA- 
kapcsolat egyeztetését. Amennyiben ez sikerrel jár, 

a Hálózati kapcsolatok (Network Connections) között olyan 
jelzésnek kell megjelennie, mely szerint a vezeték nélküli 
hálózati kapcsolat hitelesítése sikeresen megtörtént. 


Osszefoglalás 

Messzire jutottunk, remélem, mindenki követni tudott, 

és a továbbiakban senki számára nem okoz gondot a WPA 
használata. Bár a WPA távolról sem tökéletes — valójában 

a jelszóval védett ügyféltanúsítványoknak a jelszavak 

nyílt szövegben való tárolása nélküli kezelésére is képes 
WPA kérvényezőkre volna szükség -, azért elmondhatjuk, 
hogy a vezeték nélküli hálózatok végre elindultak a bizton- 
ság irányába. 
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Dinamikusan előállított naptárak 


Jó lenne, ha weboldalunk figyelmeztetni tudná a felhasználókat a közeljövő 
eseményeire, esetleg az egész cégnek közös, szinkronban tartott naptárat 


mor 


biztosítana? Python alatt iCalendar fájlokat előállítva mindez valósággá válhat. 


múlt alkalommal a Sunbirddel, a Mozilla 
A Foundation naptárkövetésre alkalmas önálló 

alkalmazásával ismerkedtünk meg. Mint láttuk, 
a Sunbird képes az iCalendar formátumú naptárak kezelé- 
sére. A naptárak a helyi fájlrendszerben is lehetnek, de 
HITP-n keresztül távoli kiszolgálóról is lekérhetők. Láttuk 
azt is, hogy a Sunbirddel milyen egyszerű egy távoli ki- 
szolgálón található naptárat használni. Egyszerűen be 
kell írnunk a megfelelő URL-t egy párbeszédpanelen, 
majd miután a Sunbird letöltötte az iCalendar fájlt, 
az új események máris megjelennek a képernyőnkön. 
Az interneten már jelenleg is számos különböző távoli, 
iCalendar formátumú naptárat találunk, megkeresésük 
és előfizetésük viszonylag egyszerűen letudható. Persze 
mindennek csak akkor van haszna, ha már meglévő, a nyil- 
vánosság számára elérhetővé tett naptárat szeretnénk igény- 
be venni. De mi legyen, ha szervezetünk az iCalendar formá- 
tumra akarja alapozni a belső adatcserét? Hogyan tudunk 
iCalendar fájlokat létrehozni és terjeszteni, lehetővé téve, 
hogy mások is értesülhessenek az őket érintő eseményekről? 
Ebben a hónapban az iCalendar fájlokkal kapcsolatos, a kiszol- 
gáló oldalra vonatkozó tudnivalókat tekintjük át, valamint 
naptáralkalmazások — mint a Sunbird — általi letöltésre, szerve- 
zeten belüli használatra szánt naptárakat fogunk készíteni. 


iCalendar fájlok 

Ha két számítógép között naptárakat akarunk cserélni, nyil- 
ván szükségünk lesz egy szabványra, mely meghatározza, 
hogy ezeket a naptárakat hogyan kell formázni. A továbbí- 
tásra használt protokoll jelenleg nincs meghatározva, ám 

a szabványok és a napi gyakorlat egyaránt arra utal, hogy 

a HTTP csaknem kizárólagos szerepet nyert a hasonló átvi- 
telek kezelésében. A naptárcsere formátuma, mely az RFC 
2445 dokumentumban található, tükrözi korának színvona- 
lát. Míg egy új naptárformátum kétségtelenül XML-re épül- 
ne, az 1998-ban született RFC még név-érték párokat alkal- 
maz, az elemeket egyszerű hierarchiába rendezve. Példa- 
ként vegyük elő a múlt hónapban, a Sunbird megismerése- 
kor is látott iCalendar fájlt: 


BEGIN : VCALENDAR 
VERSION 
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:2.0 
PRODID 
:-//Mozilla.org/NONSGML Mozilla calendar Vv1.0//EN 
BEGIN: VEVENT 
UID 
:05e55cc2-1dd2-11b2-8818-f578cbb4b77d 
SUMMARY 
:Linuxvilág határidő 
STATUS 
: TENTATIVE 
CLASS 
: PRIVATE 
X-MOZILLA-ALARM-DEFAULT-LENGTH 
50 
DTSTART 
:20050211T140000 
DTEND 
:20050211T150000 
DTSTAMP 
:20050209T1322317Z 
END: VEVENT 
END : VCALENDAR 


Mint látható, a fájl a BEGIN : VCALENDAR címkével kezdődik és 
az END : VCALENDAR címkével végződik. A fájl tetején néhány 
a teljes naptárra érvényes adat található, ilyen a VERSION és 
a PRODID, alattuk azonban már kezdődik is az első és egyben 
egyetlen esemény, melyet a BEGIN: VEVENT és a END : VEVENT 
címke fog közre. Nyilván nem okoz nehézséget elképzelni, 
hogy nagyobb számú eseményt hogyan tárolna a fájl. 

Az iCalendar rendszeres időközönként megismétlődő ese- 
mények megadását is lehetővé teszi. Egyetlen VEVENT be- 
jegyzés is elég tehát ahhoz, hogy jelezzünk egy minden 

hét hétfő délutánján megtartott értekezletet vagy figyel- 
meztessük magunkat arra, hogy kedden és pénteken ki 

kell tennünk a kukát. Minden eseménynek van kezdő 

és záró időpontja, ez a DTSTART és a DTEND, az események 
hossza gyakorlatilag tetszőleges. 

Bár a fenti példából nem tűnik ki, az iCalendar az ismétlődő 
eseményeknél kivételek megadását is lehetővé teszi. Ha 
például a hétfő délutáni értekezletre nyaralás közben nem 
akarunk elmenri, akkor egy EXDATE bejegyzéssel jelezhet- 











1. kódrészlet static-calendar.py, egyszerű, Pythonban 
készült CGI program iCalendar fájl megnyitására és 
HTTP feletti elküldésére 


4! /usr/bin/python 

f$ A CGI modul beemelése 

import cgi 

ft Az esetleges hibák naplózása 

import cgitb 

cgitb.enable(display-0, logdir-"/tmp") 

ff Hol van a naptárfájl? 

calendar directory — 
"/usr/1local/apache2/calendars/?" 

calendar file - calendar directory - "test.ics"7" 
ft content-type fejrész küldése a felhasználó 
böngészőjének 

print "Content-type: text/calendarmw" 

tf A fájl tartalmának elküldése a böngészőnek 
calendar filehandle - open(Ccalendar file, "rb") 
print calendar filehandle.readO 

calendar filehandle.closeO 


jük távol maradásunkat. A naptárat megjelenítő alkalmazás 
ezt követően figyelmen kívül hagyja az adott dátumra eső 
ismétlődő eseményt. 


iCalendar fájlok közzététele 

Ha már van iCalendar fájl a rendszerünkön, ennek közzé- 
tétele rendkívül egyszerű. Az 1. kódrészlet egy egyszerű, 
Pythonban készült CGI programot tartalmaz, mely meg- 
keres egy iCalendar fájlt a megadott könyvtárban, majd 
visszaadja a fájl tartalmát a kérést intéző naptáralkalmazás- 
nak. Aki még nem írt CGI programot Pythonban, az a fenti 
példa alapján talán már rájött, mennyire egyszerű is az 
egész. Az alapvető CGI szolgáltatások eléréséhez be kell 
tölteni a CGI modult. A következő lépés a cgitb, a CGI 
visszakövető modul betöltése, amellyel hiba esetén hiba- 
kereső adatokat tudunk írni egy fájlba. 

A következő a text/calendar tartalomtípus (content-type) 
fejrész elküldése. Feltételezhetjük, hogy a webes tartalmak 
túlnyomó részének tartalomtípusa text/html (HTML formá- 
zású szöveg) vagy text/plain (egyszerű szöveges fájl), ami- 
hez különféle image/jpeg, image/png és image/gif elemek 
társulnak. Az iCalendar szabvány szerint a naptárfájlokhoz 
text/calendar típust kell rendelni, még akkor is, ha a Sunbird 
és a hozzá hasonló programok a fext/plain formátumot is 
elfogadják. A program utolsó lépése a naptárfájl tartalmá- 
nak elküldése, amelyet a helyi fájlrendszerből olvas ki. 

Aki még egyáltalán nem foglalkozott webes programozás- 
sal, annak alighanem tökéletesen értelmetlennek tűnik 

a fenti példa. Például teljesen eszement dolognak tűnik az, 
hogy külön programot írunk egy állandó fájl tartalmának 
elérésére — csakhogy így megtehetjük, hogy a külvilág felől 
elfedjük a naptárfájl valódi helyét. Persze vannak erre jobb 
megoldások is, például az Apache Alias utasításának hasz- 
nálata. A programot továbbfejleszthetnénk úgy, hogy 

a naptárfájl nevét átadott értékként közöljük vele, ám ilyen- 
kor is szükségünk lenne állandó jelleggel rendelkezésre 
álló, előre elkészített fájlokra. 
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iCalendar létrehozása 

A valódi megoldás, ami persze érdekesebb is, az, hogy az 
iCalendar fájlt menet közben, a felhasználó kérésének hatá- 
sára hozzuk létre. A CGI program tehát nem egy meglévő 
iCalendar fájl tartalmát adja vissza, hanem maga állítja azt 
elő, majd átadja a felhasználó naptár-ügyfélprogramjának. 
Első ránézésre ennek megvalósítása egyszerűnek látszik. 
Végül is, az iCalendar fájlformátum egyszerűnek tűnik, va- 
lószínűleg nem okoz gondot a program összeállítása. Ha vi- 
szont jobban megvizsgáljuk, rájövünk, hogy az iCalendar 
fájlt létrehozni sokkal nehezebb, mint beszélni róla, különö- 
sen, ha ismétlődő eseményeket is meg akarunk adni. 
Figyelembe véve az iCalendar szabvány növekvő népszerű- 
ségét és a nyílt forrású tervezetek megszámlálhatatlan soka- 
ságát, meglepve tapasztaltam, hogy az iCalendar a legna- 
gyobb nyílt programozói közösségek részéről is csak mini- 
mális figyelmet érdemelt ki. Meglepetésem annak is volt 
köszönhető, hogy az iCalendar évek óta létezik, számtalan 
vállalat és naptárprogram támogatja, kezdve a Novell 
Evolutiontól, a Lotus Noteson keresztül egészen a Microsoft 
Outlookig. Az ilyen nagymértékű támogatottság általában 
sokféle nyelvre kiterjedő, gazdag választékot eredményez. 
Először a Perl környékén tapogatóztam; a CPAN archívum 
számos moduljának, köztük a különféle internetes szabvá- 
nyokkal kapcsolatosaknak köszönhetően méltán szerzett el- 
ismerést. Furcsa, hogy bár iCalendar fájlok feldolgozásához 
több Perl modul közül is válogathatunk, létrehozásukhoz 
egyetlen naprakész modul sem létezik. A Net::ICal::Libical 
például egy burkoló lett volna a C-ben készült libical 
könyvtárhoz, ám utolsó kiadása egy alfa változat előtti cso- 
mag. A Net::ICal a ReefKnot tervezet része volt, ami a jelek 
szerint szintén félbemaradt. 

Szerencsére egy dán fejlesztő, Max M (lásd az internetes 
forrásokat) nemrég úgy döntött, hogy pótolja a hiányossá- 
gokat, és készített egy iCalendar fájlok egyszerű létrehozá- 
sára használható Python csomagot. Én minden gond nélkül 
le tudtam tölteni és telepíteni tudtam a csomagot a gé- 
pemre, és jómagam is úgy találtam, hogy rendkívül könnyű 
vele naptárat készíteni. Korábbi egyszerű kis CGI progra- 
munkkal együtt alkalmazva kiválóan megfelel naptárak 
létrehozására és közzétételére. 


Dinamikus naptár létrehozása 

A maxm.dk oldalról letöltöttem az iCalendar csomagot, majd 
telepítettem. Sok korszerű Python csomaggal ellentétben 
telepítése nem önműködő, vagyis kézzel kell bemásolnunk 
rendszerünk site-packages könyvtárába, ami az én Fedora 
Core 3 alapú gépemen a /usr/lib/python-2.3/site-packages volt. 
Amint a 2. kódrészletből is látható, az újonnan telepített 
iCalendar csomaggal Calendar (naptár) és Event (esemény) 
típusú objektumokat hoztam létre. Az első teendőm a meg- 
felelő csomagok beemelése volt az aktuális névtérbe: 


from icalendar import Calendar, Event 


Az iCalendar csomag Calendar és Event modulja rendre 

a teljes iCalendar fájlhoz és azon belül egy-egy eseményhez 
tartozik. A Calendar objektumból tehát egy példányra van 
szükségünk, míg minden eseményhez egy-egy Event objek- 
tumnak kell tartoznia. 
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2. kódrészlet dynamic-calendar.py, iCalendar 
formátumú naptárat előállító program 


1! /usr/bin/python 

f A CGI modul beemelése 

import cgi 

from icalendar import Calendar, Event 
from datetime import datetime 

from icalendar import UTC § időzóna 

f Az esetleges hibák naplózása 

import cgitb 

cgitb.enable(display-0, logdir—"/tmp") 

ft content-type fejrész küldése a felhasználó 
ítt böngészőjének 

print "Content-type: text/calendarww" 
tf Naptárobjektum létrehozása 

cal - CcalendarO 

ft Milyen termék hozta létre a naptárat? 
cal.add( "prodid" , 

"-//Python icalendar 0.9.3//mxm.dk//") 
ft Az RFC 2445-nek a 2.0-s változat felel meg 
cal.add( "version? , "2.07) 
ft Esemény létrehozása 
event - Event 
event . add( "summary" , 
event. add("dtstart" , 


"ATF határidő") 


datetime(2005 , 3,11,8,0,0, tzinfo-UTCO)) 
event. add("dtend" , 


datetime(2005 , 3,11,10,0,0, tzinfo-UTCO ) ) 
event. add( "dtstamp" , 


datetime(2005 , 3,11,0,10,0, tzinfo-uUTcCO )) 
event["uid"] —- "ATF2OOS5OZ1l]AGlerner.co.il" 

f Kapjon kiemelt fontosságot! 
event. add( "priority", 5) 

ft Az esemény hozzáadása a naptárhoz 

cal.add component(event) 

ft A naptár utasítása önmaga leképezésére 
icalendar 

ft fájlként, majd a fájl átadása a HTTP válaszban. 
prünttcalóaséstrüingó 


Ezután megalkothatjuk a calendar objektumot: 


cal - CalendarO 
cal.add("prodid" , 

"-//Ppython icalendar 0.9.3//mxm.dk//") 
cal.add( "version? , "2.07) 


A második és a harmadik sorban, ahol a cal . add) eljárást 
hívjuk meg, módunk nyílik azonosító adatok hozzáadására 
az iCalendar fájlhoz. Az elsővel megadhatjuk az ügyfél- 
programnak, hogy milyen alkalmazás hozta létre az 
iCalendar fájlt. Ez főleg hibakeresésnél hasznos; ha rendsze- 
resen hibás iCalendar fájlokat kapunk egy megadott prog- 
ramcsomagtól, akkor kapcsolatba tudunk lépni a készítővel 
vagy a terjesztővel, és jelenthetjük neki a hibát. A második 
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sorban a változatazonosítót adtuk hozzá, amivel azt jelez- 
zük, hogy az iCalendar előírások melyik változatát követ- 
jük. Az RFC 2445 értelmében ennek a mezőnek 2.0 értéket 
kell adnunk — már amennyiben követni kívánjuk a doku- 
mentum előírásait. 

Most, hogy megvan a naptárunk, adjunk hozzá egy ese- 
ményt, amelyet egészítsünk ki egy összegzés sorral; utóbbi 
az iCalendar fájlra előfizető személyek naptáralkalmazásá- 
ban fog megjelenni: 


event - EventŐ 
event. add( "summary", "ATF határidő") 

Mint a példatfájlnál is láttuk, minden eseményhez három 
dátum/idő mező tartozik: a kezdés dátuma és időpontja 
(dtstart), a befejezés dátuma és időpontja (dtend) és az az 
időpont, amikor a bejegyzés bekerült a naptárba (dtstamp). 
Az iCalendar szabvány egy meglehetősen furcsa formátum 
szerint tárolja a dátumokat és az időpontokat, ám az Event 
objektum tudja ezeket kezelni, ha ő maga datetime objektu- 
mot kap a normál datetime Python csomagtól. Tehát: 


event.add("dtstart" , 
datetime(2005,3,11,14,0,0, tzinfo-UTCO ) ) 
event. add("dtend" , 
datetime(2005 , 3,11,16,0,0, tzinfo-UTCO ) ) 
event.add("dtstamp" , 
datetime(2005,3,11,0,10,0,tzinfo-uUTCO )) 


Megjegyezném, hogy időzónaként mindhárom esetben 
UTC-t adtam meg. Amikor az ügyfélalkalmazásban meg- 
jelenik az iCalendar fájl tartalma, akkor természetesen 

a felhasználó a saját időzónája szerint látja a bejegyzéseket, 
és nem UTC szerint. 

Az eseményeknek létrehozásuk után egyedi azonosítót kell 
adni. Az egyediség alatt itt valódi, a világ minden számító- 
gépének minden naptárára kiterjedő egyediséget kell érte- 
ni. Ez elég fogós dolognak hangzik, de nem kell megijedni 
tőle. Sokféle megoldás létezik, az egyik az, hogy a létreho- 
zás időbélyegét, az esemény létrehozására használt számí- 
tógép IP-címét és egy nagy véletlenszerű számot kombiná- 
lunk. Én egy egyszerű LIID előállítása mellett döntöttem, de 
ha olyan alkalmazást készítünk, amelyet több számítógépen 
is használni fognak, akkor érdemes alaposabban átgondolni 
és egységesíteni az azonosítók létrehozását: 


event[/uid"] - "ATF2OO5OZ1lAGlerner.co.il" 

A végső lépés az esemény fontosságának, prioritásának 
megadása, mely 0 és 9 között lehet. A normál, átlagos 
fontossági szint az ötös, a sürgősebb elemeknek nagyobb, 
a kevésbé sürgőseknek kisebb fontosságot kell adni: 
event.add( "priority", 5) 

Az eseményt létrehozása után csatolni kell a naptár objek- 
tumhoz, mely jó ideje csak arra vár, hogy végre kezdjünk 


vele valamit: 


cal.add component(event) 








Szükség szerint további eseményekkel is bővíthetjük 

a naptárat, csak az UID mező egyediségére ügyeljünk. 
Végül Calendar objektumunkat az as. string() eljárás 
segítségével beírjuk egy iCalendar fájlba: 


print cal.as stringO 


Mivel a print alapesetben a szabványos kimenetre ír, a CGI 
programok szabványos kimenete viszont a HTTP ügyfél 
felé irányul, végeredményként az iCalendar fájlt a HTTP 
kérést indító ügyfélnek küldjük el. MIME típusként 
text/calendar-t választottunk, vagyis a HTTP ügyfél tudni 
fogja, hogy a kapott adatokat naptárként kell értelmeznie, 
illetve képes lesz azok helyes megjelenítésére. Ha megvizs- 
gáljuk a kimenetet, láthatjuk, hogy valóban iCalendar for- 
mátumú: 


BEGIN : VCALENDAR 
PRODID:-//Python iCalendar 0.9.3//mxm.dk// 
VERSION:2.0 

BEGIN: VEVENT 
DTEND:20050311T160000Z 
DTSTAMP : 20050311T0O01000Z 
DTSTART:20050311T140000Z 
PRIORITY:5 

SUMMARY:ATF határidő 

UID: ATF2O0O5OZ1]AGlerner. co. il 
END: VEVENT 

END : VCALENDAR 


Látogasson el hozzánk! 


Virtuális könyvesboltunk egyedülálló választékot kínál 


Be kell vallanom, az előzőhöz hasonlóan ez a példa is egy 
kicsit mesterkélt volt. Igaz ugyan, hogy a naptárat dinamiku- 
san állítottuk elő, de az esemény bele volt drótozva a prog- 
ramba, így módosítása, hozzáadása vagy törlése csak a prog- 
ramozó számára lehetséges. Fogalmazzunk tehát úgy, hogy 
újabb lépést tettünk az események és dátumok programból 
történő előállítása felé. A következő az lesz, hogy a dátumo- 
kat fájlban vagy akár relációs adatbázisban helyezzük el, 

és a programmal az adatokat futás közben alakítjuk át. 


Osszefoglalás 

Ebben a hónapban megvizsgáltuk a dinamikus naptárak 

a Python egy egyszerű CGI programba burkolt iCalendar 
moduljával végzett előállítását. Ugyanakkor láttuk azt is, 
hogy milyen korlátai vannak egy olyan naptárnak, amely- 
nek bejegyzéseit a merevlemezen tároljuk. Jobb megoldás 
lenne, ha az események adatait egy relációs adatbázisban 
helyeznénk el, amely önmagában is képes a dátumok keze- 
lésére, valamint megfelelő eljárásokat biztosít a felhaszná- 
lók és a csoportok hozzáférésének szabályozására. A követ- 
kező alkalommal tovább bővítjük a naptárprogramot, 
adatait adatbázisból fogja venni, az iCalendar fájlokat 
PostgreSOL táblák alapján fogja előállítani. 
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FreeBSD - a szomszéd vár 99. rész) 


A várboörtoön cellái 


Gyakran kerülhetünk olyan helyzetbe, amikor meg kell védenünk a rendszerünket 
egy szolgáltatástól, esetleg önmagától, vagy a többi programtól, a külső-belső tá- 
madásoktól, illetve a sérülékeny vagy könnyen támadható az adatokat mindezektől. 
A probléma megoldása egyszerű, a szolgáltatásokat bezárjuk egy börtön cellájába: 


ez a jail alrendszer. 


Mi az a jail? 

A Linux esetén már ismert chroot program távoli rokona, 
amellyel FreeBSD alatt tudunk programokat elzárni a rend- 
szer többi részétől; egy kicsit másképp és egy kicsit jobb kö- 
rülmények között. A jail ugyanis FreeBSD virtuális gépe- 
ket hoz létre, amelyeknek közös rendszermaggal bírnak, 
viszont minden mást külön kezelnek. A gépen kívülről néz- 
ve egy jai1 alrendszer olyan, mintha lenne még számítógé- 
pünk, amelyeken ugyan az a FreeBSD van, mint a mellette 
lévőkön (holott csak egy gépünk van). Minden virtuális 
gépnek van egy külön IP címe, amelyre hallgat, a rendszer 
többi részével csak (virtuális) hálózati felületeken tud kom- 
munikálni, leszámítva a megadott könyvtárstruktúrát, ame- 
lyek a rendszermagon keresztül képes kezelni. Azt tudom 
mondani, hogy a FreeBSD jai1 megvalósítása többet tud, 
mint a Linux chroot (teljesen elszeparált virtuális gép); 
kevesebbet tud, mint az UML (User Mode Linux), mivel 

a rendszermag közös, az nem cserélhető. 


Miképp készül? 

A bebörtönzést elő kell készíteni, amely tevékenység alatt 
az alaprendszer könyvtárainak és állományainak a jai1 
könyvtárába való másolását értjük; ezen túl néhány beállí- 
tás is szükséges lehet, hogy a bebörtönzött folyamat megfe- 
lelően tudjon működni. 

Általában két módszer közül választhatunk, mind a kettő 
célravezető, de más-más módon éri el a biztonságos üze- 
meltetést. Megtehetjük, hogy a teljes telepítés után eltávo- 
lítjuk az állományok és könyvtárak egy részét, egészen 
addig, amíg még működőképes a bebörtönzött program 
(kövér modell). Esetleg egyenként másoljuk át az állomá- 
nyokat, és a könyvtárakat, egészen addig, amikor már 
működőképes a program (sovány modell). Akár a kettő 
módszert kombinálhatjuk is, felmásolunk egy-egy könyvtá- 
rat, majd elkezdjük törölgetni a mappából az állományokat. 
Az interneten keresgélve nagyon valószínű, hogy megtalál- 
juk a kész recepteket az adott szolgáltatás működéséhez 
minimálisan szükséges állományok listájával együtt. 
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A börtön felépítését sok különféle módon tehetjük meg, 
ebből három módszert szoktunk használni: mezei másolás, 
a make world parancs segítségével, illetve egy külön telepí- 
tett programot használva. 

A mezei másolás okán egyszerűen átmásoljuk a jail 
könyvtárába azokat az állományokat, amelyek szükségesek 
a bezárandó programunk futásához (és magát a futtatandó 
programot is). Gyakorlatilag ez a legegyszerűbb megoldása 
a börtönünk létrehozásának, bár kétségkívül nagyobb szak- 
értelmet kíván. Sajnálatos, hogy a börtön karbantartása is 
nehezebb így, mint a többi módszert használva. 

A klasszikus (leginkább támogatott) módszer szerint egy 

új alaprendszert építünk fel a börtön egy-egy cellájában. 
Teljesen azonosan kell eljárnunk, mint az alaprendszer fris- 
sítésénél, egyetlen paraméterrel kell többet megadnunk: 
hol készüljön el az új alaprendszer, illetve néhány más 
parancsot is végre kell hajtanunk. 

f export JAILDIR-/usr/local/jails/10.1.1.213 

cd /usr/src 

mkdir -p $JAILDIR 

make world DESTDIR-$JAILDIR 

cd $IJAILDIR 

ln -sf dev/null kernel 


tk dik tk odk tk 


Ezzel a tevékenységgel számítógépünk ugyan annyi időt 
tölt el, mint az alaprendszer frissítésével, tehát akár több 
órán át is tarthat. Ha gyakran kell jai 1 rendszert elkészíte- 
nünk, akkor érdemes egy példányt eredeti állapotában 
megtartani, s így csak át kell másolnunk a teljes könyvtár- 
szerkezetet. Ezzel a módszerrel egy börtöncella mérete 
azonos lesz a teljes alaprendszer méretével, vagyis közel 
200MBájt helyet fog elfoglalni. Ezen a hatalmas méreten 
sokat tudunk csökkenteni, ha a felesleges részeket eltávolít- 
juk (dokumentáció, kézikönyv oldalak, stb.). 

Második legnagyobb szakértelmet kívánó kihívás 

a sysinstall] program használata a jai1 beállításához. 
Ekkor alapvetően egy programot kell felmásolni a börtö- 
nünk könyvtárába: a /stand/sysinsta11 állományt. 











$ mkdir $JAILDIR/stand 
$ cp /stand/sysinstall $JAILDIR/stand 


A bebörtönzés elindításához szükséges a helyi hálózathoz 
hozzáadni egy IP címet (például 10.1.1.213), ahol elérjük 
majd a börtönükbe bezárt programjainkat. 

tf ifconfig vrO alias 10.1.1.213/32 


Két fontos könyvtár van, amit nem tudunk könnye- 
dén létrehozni, a dev és a proc, amelyek speciális 
fájlrendszert hordoznak: a devfs és a procfs nevűt. 
Ezt a két fájlrendszert fel kell csatolnunk msinden 
egyes jail könyvtárba. 

f mkdir dev 

$ mount devfs devfs $JAILDIR/dev 

$ mkdir proc 

íf mount procfs proc $JAILDIR/proc 


Az alaprendszer elkészítése nem vonja maga után a /etc 
könyvtár elkészítését (amely teljesen érthető a make world 
alapvető feladatát tekintve), így ezt külön parancs segítsé- 
gével kell nekünk elkészítenünk. 

$ cd /usr/src/etc 

$ make distribution DESTDIR-$JAILDIR 


Nincs más hátra, mint beállítani a börtön kényelmi szolgál- 
tatásait, ehhez már be kell térnünk a cellába is. A jail pa- 
rancs szolgál a bebörtönzés elindítására, amelynek az első 
paramétere az elkészített könyvtárszerkezet belépési pont- 


ja, a második paramétere a börtön neve, harmadik paramé- 
tere a kiválasztott IP cím, majd ezeket követi a végrehaj- 
tandó parancs elérési úttal együtt. 

ft jail /usr/local/jails/10.1.1.213/ private213 
510.1.1.213 /rescue/sh 


A kapott üres parancssorba kezdésképp a sysinstal1 
programot írhatjuk. 
$ /stand/sysinstal1 


Nem kell meglepődni, megkapjuk a FreeBSD telepítésénél is 
kapott programot, amellyel most újra feltelepíthetjük a Free- 
BSD rendszerünket: a jai1 alrendszer ugyanis olyan, mint 
egy teljesen új telepítés. A rendszermag már fut, az alaprend- 
szer rendelkezésre áll, de semmi egyéb nincs beállítva, enge- 
délyezve: mindent újra be kell állítanunk és engedélyeznünk. 
Az első használatbavétel előtt — amikor már a bebörtönzött 
programunkat szeretnénk futtatni — érdemes a /sbin/init 
programot elindítani a jai1 első beállításához (SSH kulcsok 
elkészítése, stb.). Nem kell megijedni, a képernyőkép telje- 
sen azonos lesz, mint amikor a FreeBSD rendszerünk elin- 
dul, hiszen a virtuális gépünkben is egy FreeBSD indul el. 
Programok telepítése és karbantartása azonos módon törté- 
nik, mint azt a börtönünkön kívül tettük, így az alaprend- 
szer frissítése és a ports adatbázis is járható út. 


Segédprogramok 
Érdemes néhány segédprogramot telepíteni, amelyek 
sokat segítenek a börtönünk felügyeletében. Néhány 
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programot a börtöncellába kell telepíteni, némelyiket 

a börtönön kívülre. A legfontosabb a jailutils csomag, 
amely a börtönön belül futó programok kezelésében segít 
(jps, jtop, jki11), mivel a jail belső mechanizmusai 
ezen programok normál futását jelentősen befolyásolják. 
A jailadmin vagy a jailct1 csomag a börtönök elindítá- 
sában, leállításában; illetve elkészítésében is segítséget 
nyújtanak. 


A börtöncella beállítása 

Fontos tulajdonsága a jail rendszernek, hogy nem 
hallgatózik a számítógépünk összes elérhető hálózati 
felületén, csak a parancssorban megadott IP címen. 

Ha megnézzük a börtönünkön kívül a vrO eszközhöz 
rendelt címeket, akkor láthatjuk, hogy több címe is van, 
azonos fizikai címmel. 


ít ifconfig vr0O 
vro: 
flags-8843-cUP , BROADCAST , RUNNING , SIMPLEX , MULTICAST2 
Smtu 1500 
inet 10.1.1.211 netmask OXxffffff00 
s broadcast 10.1.1.255 
inet6 fe80::211:5bff:fe09:782aXvrO 
sprefixlen 64 scopeid 0x2 
inet 10.1.1.213 netmask OXxXffffffff 
s broadcast 10.1.1.213 
ether 00:11:5b:09:78:2a 


A jail rendszeren belül szintén megtaláljuk ezt az eszközt, 
de már csak a saját IP címével, a többi cím nem is látszik. 


$ ifconfig vrO0 
vro: 
flags-8843-cUP , BROADCAST , RUNNING , SIMPLEX , MULTICAST- 
Smtu 1500 
inet 10.1.1.213 netmask OXFffffffff 
broadcast 10.1.1.213 
ether 00:11:5b:09:78:2a 


Ha ki szeretnénk próbálni a jail hálózatának működőképes- 
ségét, nem várt problémába ütközhetünk. 

$ ping 10.1.1.212 

ping: socket: Operation not permitted 


A ping működéséhez igazzá kell állítani 
a security.jail.allow raw socket rendszerváltozót még 
a jai1 elindítása előtt. 


ff sysctl -a security.jail.allow raw sockets-1 
security.jail.allow raw sockets: 0 -5 1 

ff jail /usr/local/jails/10.1.1.213/ private213 
510.1.1.213 /rescue/sh 

$ ping 10.1.1.212 

PING 10.1.1.212 (10.1.1.212): 56 data bytes 
64 bytes from 10.1.1.212: icmp seg-0 tt1l-64 
5 time-7.635 ms 


E nélkül csak a TCP és az UDP csomagokat jutnak ki 
a börtönből, ha például ICMP csomag is szükséges, 
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akkor ezt a beállítást tegyük meg. Ez az engedélyezés 
viszont biztonsági kockázatot is jelent, így csak vég- 
szükség esetén használjuk; célravezetőbb egy olyan 
helyettesítő eszköz használata, amely TCP porton át 

is képes a hálózat működőképességét ellenőrizni (például 
az echoping csomag). 

A hálózat többi beállítása (gazdagép neve, útválasztás, név- 
feloldás, stb.) azonos módon történik az alaprendszer tele- 
pítéskori beállításaival, használjuk nyugodtan erre a célra 

a sysinstal ] programot. 


Lemezkezelés 

A börtönben futó program nem látja a külsőleg felcsatol 
állományrendszereket, csak a saját főkönyvtárát tartalmazó 
fájlrendszert tudjuk lekérdezni. 


$ df 
Filesystem 
s Mounted on 
/dev/adosif 150307738 16267994 134039744 
7 /usr 


1K-blocks used Avail Capacity 
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Néhány tanács és pár megjegyzés 

A jail nem óvja meg a gépünket a feltöréstől, mindössze 
— helyes tervezés esetén - az érzékeny adatokat védi 
meg a támadótól. Minél több jai1 készül el a gépünkön, 
annál nehezebb lesz azok karbantartása, hiszen egy-egy 
alaprendszert érintő biztonsági hiba kijavítását az alap- 
rendszerünkön és az összes jai 1] rendszerünkön is végre 
kell hajtanunk. Érdemes a jai1 belső felhasználóit lere- 
dukálni minimálisra, hiszen a legtöbb inaktív lesz. A jai1 
alkalmas arra, hogy a teljes FreeBSD rendszer rendszer- 
gazda (root) jogú adminisztrálását kiadjuk egy másik 
személynek. Ő képes belépni a megadott IP címen, 
minden frissítést, telepítést és beállítást képes elvégezni, 
viszont nem képes az alaprendszer is érintő beállítások 
elvégzésére (particionálás, fájlrendszer elkészítése, más 
fájlrendszer felcsatolása, hálózati eszközök átállítására, 
stb.). Igazából egy olyan virtuális gépet tudunk készíteni 
a kiszolgáló gépünkön, amelyet egy FreeBSD rendszert 
ismerő személy képes kezelni, s úgy tekinthet rá, mint 
egy önálló számítógépre. 


Auth Gábor (auth.gaborDenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 


kigyógyulni. 


A FreeBSD projekt honlapja: 5 http:/Avww.freebsd.org 
A magyar FreeBSD honlap: 3 http:/Avww.freebsd.hu 


A magyar BSD honlap: 5 http:/Awww.bsd.hu 


A kézikönyv magyar fordítása 
5 http:/Avww.enaplo.hu/FreeBSD/handbook/ 

















Rendet a képek között. 


a leszámítom a gyerekkori fotóimat és fényképező- 

gépemet, akkor azt kell mondjam, hogy éppen egy 

évtizede foglalkozom egy amatőr fotós szintjén 
fényképezéssel, többnyire hobbi céljából. Ennek az időnek 
a felét egy — a profi kategória küszöbét éppen átlépő — tü- 
körreflexes fényképezőgéppel fényképeztem el. Többnyire 
diafilmre dolgoztam, amit felhasználás előtt hűtőben kellett 
tárolni. Azt hiszem, részben azért tanultam meg jól fényké- 
pezni, mert egy-egy elrontott kép okozta veszteség igencsak 
forintosítható volt. Digitális gépet egészen sokáig nem vol- 
tam hajlandó venni, mivel a beszerezhető típusok egyszerű- 
en nem feleltek meg a fotózásról alkotott elképzeléseimnek. 
Aztán egyszer csak fordult a kocka, és számomra már 
megfelelő minőséget kaptam elérhető áron. Minőségi eta- 
lonnak természetesen továbbra is a tükörreflexes gépemet 
tekintettem. Annyi történt mindössze, hogy egyszerre 
annyi pénzért tudtam megvenni egy hasonló tudású digi- 
tális gépet, mint amennyiért annak idején a közönséges 
filmre dolgozó gépemet. 
Az évtized első öt évének fényképei egy átlagos család fotó- 
albumával vannak egy , súlycsoportban". A kartondobozon 
túl nem fordítottam különösebb figyelmet ezeknek a cso- 
portosítására vagy kategorizálására. A tükörreflexes géppel 
készültekre már több gondot fordítottam, hiszen ezek több- 
ségében sok munka fekszik. A diakockákat tekercsenként 
egy-egy légmentesen lezárható dobozkába táraztam be 
diakeretekbe, amelyekre ráírtam a tekercs témáját, majd 
a diakocka száma szerint az adott képpel kapcsolatos félso- 
ros összefoglaló szöveget is feljegyeztem. 
Igazából mindig sajnáltam, hogy nem tudtam magamat 
arra rávenni, hogy minden egyes kockához leírjam 
a helyszínen a készítés körülményeit, így ezeket nem 
jegyeztem fel a kockák mellé. Havonta-kéthavonta egy 
tekercsnyi (36 diakocka) kép tárolása és leírása nem volt 
nehéz, sajnos a visszakereshetőség nem volt adott; elég 
jól ismertem a ,gyűjteményem", de mindig akadt néhány 
elfeledett fotó, amely pont akkor nem került a kezeim 
közé, amikor szükség lett volna rá. 
A digitális fényképezés egy kicsit felborította ezt az idilli 
állapotot, mivel csak a fényképezőgép tudásának megisme- 
résére való tekintettel 1200 képet készítettem az első két hét 
alatt (amelyek nagy részét aztán könnyű szívvel töröltem). 
A kattintások száma idővel csökkent, bár nem nagyon 
jutottam még a heti 50 képet jelentő álomhatár alá. Pedig 
nagyon igyekszem, csak egyszerűen minden apróságra 
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Welcome to KimDaba 


If you are interested in trying out KimDaBa with a prebuild 
set of images, then simply choose the Load demo button. 
You may get to this demo at a later time from the Help 
menu. 


Alternatively you may start making you own database of 
images, simply by pressing the Create my own database 
button 











[create my own database 








Nyitókép 
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View images (1-109) 100 images 


E) view images (101-119) 10 Images 
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A főablak 


bizseregni kezd a mutatóujjam, és valahogy nagyon 
könnyen lenyomódik az exponáló gomb... 

Amikor a digitális fényképezőgép már a második 

hónapját kezdte eltölteni a kezeim között, rájöttem: ha 

így folytatom, akkor bele fogok fulladni a képekbe. Első 
felindulásomban arra a következtetésre jutottam, hogy ke- 
resek egy programot, amely a fényképek kategorizálásában 
segít, visszakereshetővé teszi az egyes eseményeket és hely- 
színeket. Sajnos az első felindulás nem oldott meg semmit, 
a letöltött és kipróbált tucatnyi program nem váltotta be 

a hozzá fűzött reményeimet, így elkezdtem játszadozni 

a gondolattal, hogy írok egy ilyen programot. 

Nem, nem a saját programomról írom a cikket, mivel a mun- 
kát idő hiányában el se kezdtem. Viszont egy puszta vélet- 
lennek köszönhetően megtaláltam a KimDaBa csomagot. 
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Loadiny information from images 


Depending on the number of images, this may take some time. 


However, there is only a delay when new images are found. 





Read File Info 
84 selected 


IX Read time 
IX Read date 
I" Read EXIF orientation 


IX Read EXIF description 


hi Cancel 





EXIF információk 
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Showiny 64 images ! Total: 327 





Előképek 


Egyszerűen a Beep Media Player médialejátszó programot 
szerettem volna megkeresni a FreeBSD rendszerem csomag- 
adatbázisában és erre a ,bmp" szöveget találtam a legkifeje- 
zőbbnek. Sajnos a BMP programot nem találtam a kapott lis- 
tában, viszont az , Image database for KDE" szöveget annál 
inkább. Ez mindössze annyi kapcsolatban volt a ,bmp" kere- 
sési feltétellel, hogy történetesen BMP formátumú képeket 
is kezel. Kaptam az alkalmon, és feltelepítettem a KimDaBa 
programot, a médialejátszó program telepítése pedig teljes 
feledésbe került. Igazából csak most jutott eszembe amint 
ezt a cikket írom. Tehát: ezennel megragadom az alkalmat, 
és minden kedves olvasóm szíves figyelmébe ajánlom a Beep 
Media Player programot, amiről a fenti malőrnek köszönhe- 
tően a nevén kívül egyelőre nem sokat tudok. 
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És most vissza a KinDaBa-hoz. Bizonyosság híján csak 
remélni merem, hogy a főbb Linux terjesztések tartal- 
mazzák ezt a remek programot. Ha mégsem, akkor 

a 5 http://ktown.kde.org/kimdaba címről is letölthető. 
Verziószám szerint már a 2.1-es változatnál tart a fejlesztő- 
csapat, így bizton remélhetjük, hogy kiforrott és könnyen 
kezelhető a program. Én egy ideje a 2.0 verziót használom 
3.4-es KDE rendszer alatt. Sajnos magyarítás nincs hozzá, 
de az általános használatához elegendő néhány alapvető 
angol szó ismerete. (Amúgy pedig várom azokat a jelent- 
kezőket, akik segítenének a program magyar változatának 
elkészítésében.) 

Mindenképpen javaslom a programmal érkező demó 
megnyitását, mivel ezzel egy már jól beüzemelt fotóalbu- 
mot tudunk megtekinteni (átlagos családi fotóalbummal). 
Ezek után készítsük el a saját adatbázisunkat, amelynek 
egy külön mappában adjunk helyet (ennek a neve találóan 
lehet mondjuk KimDaBa). 

Érdemes megjegyezni, hogy a megadott könyvtárba 
kezdésképp nem tanácsos túl sok fényképet tenni, mert 

a program az összeset betölti, átnyálazza és begyűjti a hoz- 
zájuk tartozó információkat. Mármost ha az első futtatás 
során minél hamarabb meg szeretnénk ismerni a program 
szolgáltatásait, nem szerencsés, ha induláskor ki kell várni 
azt a tizenhét percet, amíg a rendszer az említett könyvtár- 
ban található 2553 képet feldolgozza. (Igen, tapasztalatból 
írom ezt...) 

A program fő ablaka puritán, vagy ha így jobban tetszik 
kényelmes és átlátható. Mellőz mindennemű céltalan 
díszítést. A képeinket mappa, kulcsszó, helyszín vagy 
személy szerint tudjuk csoportokba rendezni. Alapesetben 
egyetlen nagy csoportunk van, hiszen nem adtunk meg 
kategóriákat. 

Az első és legfontosabb feladat a képek mappákba rendezé- 
se, mivel így később sokkal hatékonyabban tudunk szortí- 
rozni. Érdemes egy , ömlesztett" könyvtárat is fenntartani, 
ahova az újabb képeket tudjuk bemásolni a fényképező- 
gépről. (Erre a célra én az induló könyvtárat tartom fenn.) 
A kezdeti néhány képen kívül másoljunk bele a KimDaBa 
könyvtárába néhány képet, amelyet már előzőleg 
mappákba szortíroztunk, s szólítsuk fel a képek újraol- 
vasására, amelyet a Maintenance/Rescan for Images me- 
nüpontban tehetünk meg. A bemásolt képek mennyisé- 
gétől függően a program rövidebb-hosszabb ideig keresi 
a változásokat. 

Válasszunk ki egy szimpatikus mappát — esetemben 

ez a Mecsek/Égervölgy 2005. 04. 23. nevű lesz — s 

a Maintenance/Read EXIF info from files... menüpont 
segítségével dolgoztassuk fel a programmal a képekben 
található EXIF információkat (blende, expozíció ideje, gyúj- 
tótávolság, stb.). Sajnos ez a lépés egyben törli a képekhez 
rendelt saját információinkat, így mindenképpen ezzel 

a művelettel kell kezdjük a képek kezelését. 

Alapesetben csak a képhez rendelt idő és a dátum kerülne 
beolvasásra, ezért mindenképpen jelöljük be a képhez 
tartozó leírást, illetve akár az orientációt is. A beolvasás 
gyorsan megtörténik, s ha rákattintunk a , View images" 
szövegre, akkor azonnal láthatjuk is a képeket kicsiben. 
Sok kép esetén ez a művelet eltarthat egy ideig, mivel 

a program alapértelmezésként röptében gyártja le 
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Kép előnézete 


Zoom In 
Zoom Out 
Full View 
Toggle Full Screen 
Rotate 90 Degrees 4 
Rotate 180 Degrees 
Rotate 270 Degrees 
Ív. Show lnfo Box 
[9 Show Drawing 
[Show Description 
[v Show Date 
[v. Show Time 


Show Folder 


v Show Keywords 


v Show [Locations 





v Show Persons 
Set as Wallpaper 
Invoke External Program 
Draw on Image 
Edit Image Properties 
Show Category Editor 
Close 





Helyi menü 


az előképeket. Ezt a Maintenance/Build thumbnails menü- 
ponttal változtathatjuk meg, mikor is a program elkészíti 

a mappa összes tagjának az előképét. 

Ha rákattintunk egy képre, akkor a rendszer azt megmutatja 
valamivel nagyobb méretben (600x450 pixeles felbontásban). 
Jól nézzük meg ezt a kis előnézeti ablakot, mert ez a program 
lelke, noha ez elsőre nem igazán látszik rajta. De kattintsunk 
csak a jobb egérgombbal az ablak területén, s rögtön előbuk- 
kan az egyik legnagyobb méretű helyi menü. 

Ennek a legfontosabb és leggyakrabban használt pontja az 
Edit Image Properties lesz, amely egy hatalmas ablakot nyit 
meg. Ebben szépen sorban megadhatjuk a kép kiegészítő 
információit: adunk neki címkét és leírást; hozzáadjuk 

a személyek, a helyszínek, illetve kulcsszavak listájához 

a képen található látnivalókat, majd bezárjuk az ablakot. 
Ha mindent jól csináltunk, akkor a kép előnézetén már 
láthatjuk is a változásokat. 
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Keywords: TV torony — 
Locations: TV torony, Egervölgy 


Description: A pécsi TV torony 
égervölgy felől 


TV torony 


Szembetűnő változás, hogy a kulcsszavak, illetve a helyszí- 
nek és a személyek neve kék színnel jelenik meg, ráadásul 
aláhúzva: ezek bizony kapcsok a hasonló képekhez. Gyorsan 
keresünk emlékezetből néhány azonos tartalmú képet, s már 
láthatjuk is működés közben a képek közötti kapcsokat. 

Ha például egy kulcsszóra kattintunk rá, akkor a program 
kigyűjti azokat a képeket, amelyeken a kulcsszó szerepel, így 
került egymás mellé a három kép a pécsi TV toronyról. Ha 
egy képen találunk valami fontos részletet, amelyet minden- 
képpen szeretnénk megmutatni az ismerősöknek, akkor akár 
rajzolhatunk is rá a Draw on image menüponttal. Nem büsz- 
kélkedhet a program túl összetett rajzeszközökkel (vajon mi- 
ért nem integrálták a KolourPaint és a Karbon14 programot 
erre a célra?), de azért kellemesen el lehet vele szórakozni. 
Egyetlen előnye ennek a rajzoló modulnak, hogy utólag 

el lehet tüntetni a képre rárajzolt dolgokat, azok ugyanis 
nem kerülnek bele magába a képállományban. Az egysze- 
rű geometriai formák csak hozzárendelődnek a kép nevé- 
hez. Ellenben a képhez meg tudunk hívni külső programot, 
így szükség esetén professzionális eszközökkel is tudjuk 
szerkeszteni vagy retusálni. Ha pedig valamelyik fotó na- 
gyon megtetszik, egyetlen kattintással a munkaasztalunk 
hátterévé tudjuk tenni. 
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TV torony 
41-én 


TV torony 





Member Groups 
Viewer 
Preferred View: 


£ Small List View v 


Cenes 


Kategóriák szerkesztése 


New 





A program egyik lényeges tulajdonsága, hogy át tudjuk 
szabni a kategóriákat a Settings/Configure KimDaBa... 
menüpont hatására megnyíló ablak Option Groups részén. 
A magam részéről elkezdtem a magyarítást azzal, hogy 

itt a csoportok megnevezéseit átírtam. 

Érdemes hasonló módon kibővíteni a program által 
felkínált kategóriákat, így ugyanis sokkal több jellemző 
szerint tudjuk csoportba rendezni a képeket. Egy kép 
jellemzőinek szerkesztésekor azzal szembesülhetünk, 
hogy nem látjuk a módosított, illetve az újként hozzá- 
adott saját kategóriákat. Ennek valószínűsíthető oka, 
hogy a program név szerint tárolja ennek az ablaknak 
az alkotórészeit. A megoldás kézenfekvő: az Options 
nyomógomb nyomán felbukkanó menüben tegyük lát- 
hatóvá a saját kategóriáinkat is. A külön nyíló ablakokat 
rá tudjuk húzni a fő dialógusablakra, így ez már minden 
kívánalomnak megfelel. 

Ha már sikerül néhány tucat képünket a megfelelő kategó- 
riákba besorolni, akkor tovább próbálkozhatunk a program 
egyéb képességeivel. 

Három igencsak hasznos szolgáltatást találunk a File 
menüben (a mentést és a kilépést leszámítva): a képeink 
exportálását, importálását illetve egy HTML oldalba foglalt 
galéria elkészítését. 
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HTML oldal 


Az exportálás során a kiválasztott album (amelyet 

éppen nyitva tartunk) kerül ki a megadott könyvtárba. 
Alapesetben csak a kis előképek kerülnek bele egy .kim 
kiterjesztésű állományba a szükséges index.xml állo- 
mánnyal együtt. Természetesen hozzámásoltathatjuk 

a képeket is, amelyek azonban sok helyet foglalnak el, 
így érdemes megadni az átméretezést is. Készüljünk fel 
arra, hogy az átméretezés több másodpercet is elvehet 
képenként, így egy 100-200 képet tartalmazó album 
exportálása több perc is lehet. 

Az exportált állományt aztán oda tudjuk adni másoknak, 
akik képesek ezt importálni a saját képadatbázisukba. 
Egyszerűen csak ki kell választanunk a kapott állomány 
helyét, majd betölteni a képeket a megjelenő varázsló segít- 
ségével, amely lépésről-lépésre vezet minket kézenfogva. 
Nagyon érdekes a HTML album készítése, amellyel 

a weboldalak készítését spórolhatják meg a fotográfusok. 
(Őszintén szólva én nagyon szeretek weboldalakat készíte- 
ni, így engem a KimDaBa-nak ez a szolgáltatása nem annyi- 
ra vonz.) Számos jellemzőjét adhatjuk meg az elkészülő 
HTML oldalnak: címét, leírását; grafikai megjelenését, meg- 
adhatjuk a megosztani kívánt képek legnagyobb felbontá- 
sát, s végül azt a könyvtárat, ahova menteni szeretnénk 
(alapbeállításként a saját public html könyvtárunk lesz ez). 
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Naptár készítése 


A program legérdekesebb része vitathatatlanul 

a Plugins menüpont, ahol több tucat eszköz, program 

és módszer várja, hogy valamelyiket munkára fogjuk. 

Én ezek közül hármat tudok nyugodt szívvel ajánlani: 

a naptár készítését (Tools/Create Calendar...), 

a videóállományba mentett bemutatót (Tools/Create 
MPEG SlideShow...), és a CD/DVD lemezre történő 
archiválást (Export/Archive to CD/DVD...). 

A képes naptár készítése ugyan nagyon hálás feladat, csak 
a program egyes szövegeket a KDE nemzeti beállításaiból 
vesz, másokat pedig maga ír meg angol/amerikai formá- 
tumban. Az eredmény így aztán kissé felemás lesz. A nap- 
tárvarázsló első lapján az olyan feltételeket tudjuk megad- 
ni, mint a lap mérete, a kép elhelyezkedése vagy a szöveg 
stílusa. Ezt követi a képek kiválasztása, ahol a hónapokat 
látjuk egymás mellett. Ha rákattintunk egy hónapra, akkor 
a kapott listából ki tudjuk választani a kívánt képet. 

(Itt az aktuális mappában szereplő képek közül választha- 
tunk, tehát még a naptárkészítés előtt válasszunk ki olyan 
kulcsszót vagy jellemzőt, amely alapján a képek leválogat- 
hatók.) A képek kiválasztása után következhet a nyomtatás. 
A program csak azokat a hónapokat nyomtatja, amelyhez 
választottunk képet. 

Családi képeket nézegetve bennem gyakran támad olyan 
megmagyarázhatatlan inger, hogy legszívesebben mindet 
megmutatnám a család aprajának-nagyjának. Igen ám, 

de ehhez vagy vinnem kell magammal a számítógépet, 
vagy minden érintett állományról papírképet kell készíttet- 
nem. Esetleg ki is nyomtathatom őket... Az első lehetőség 
nehézkes, a többi meg drága. 

A problémának ugyanakkor van egy olyan megoldása is, 
ami egyenértékű a gordiuszi csomó átvágásával: készítsünk 
olyan bemutatót, amelyet le lehet játszani a legtöbb otthon- 
ban már megtalálható CD/DVD lejátszó készülékekkel. 
Ehhez egyszerűen a megfelelő menüpontot kell kiválaszta- 
nunk, majd néhány opciót beállítani (képek közötti szünet, 
a képek közötti átmenet ideje, háttérszín, hangállomány 
helye), illetve megadni a kész MPEG állomány végleges 
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A kész naptár egy lapja 


helyét és kiválasztani a kívánt képeket. A többit bízzuk 
nyugodtan a KimDaBa programra, illetve a K3b-re amely 
az elkészült MPEG állományt felírja egy CD lemezre. 

A digitális képeink archiválása nagyon fontos feladat, mivel 
csak és kizárólag digitális formában tudjuk veszteség nélkül 
tárolni őket. Minél fontosabb egy-egy képünk, annál inkább 
igyekezzünk minél több helyre és formában menteni. 

Az egyik legjobb módszer a CD vagy DVD lemezre történő 
írás, amely azonban csalóka lehet, mivel a lemezek nagyon 
sérülékenyek. Itt egy karcolás eredménye nem egyetlen 
karc lesz egyetlen képen, mint azt a filmes világban esetleg 
megszoktuk... 

A lényeg, hogy egyszerűen és csoportosítva mentsük a képe- 
ket, és erre a KimDaBa tökéletesen megfelelő. A lemezekre 
felkerül egy HTML oldal is, amely segít a képek közötti eliga- 
zodásban, illetve kapunk egy listát is az adott mappában ta- 
lálható állományokról. Ha valami baj történne a gépünkkel, 
akkor a mentésből szépen vissza tudjuk állítani a képeinket. 
A KimDaBa itt is a K3b íróprogramot használja a mentés elké- 
szítésére, illetve a már ismert HTML galériát a navigációhoz. 
Javaslom e menüpont gyakori alkalmazását! 


Zárszó 

Lassan két hete használom teljes megelégedéssel a KímDaBa 
programot. Bár egyelőre vannak hiányosságai, világosan lát- 
szik, hogy a fejlesztők munkája ígéretes, és határozott a fejlő- 
dés. Szinte alig tudok olyan szabad programot mondani, 
amelyik felvenné a versenyt a KimDaBa könnyed használa- 
tával és átlátható felületével; a program tudása pedig folya- 
matosan bővül. Így nem kell aggódnunk: amit ma nem tud, 
azt holnapra talán már kezelni fogja. 


Auth Gábor (auth.gaborXDenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 
kigyógyulni. 
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Hordozd a tenyereden - Linuxos PDA-k 


Korábban egy rövid cikksorozatban már bemutattuk, hogyan tudunk egyszerűen 
és gyorsan egy hordozható számítógépre Linuxot telepíteni, illetve milyen beállí- 
tások szükségesek ahhoz, hogy kedvenc operációs rendszerünk a laptopunkon 
is működjön. Most megnézzük, hogyan telepíthetünk Linuxot egy tenyérszámító- 
gépre, avagy közismertebb nevén egy PDA-ra. 


Milyen rendszer fut és milyen rendszer futhat egy PDA-n 
A palmtopokon gyári kivitelben két nagy gyártó rendszere 
fut, a PalmOS vagy a Microsoft PocketPC. A két rendszer 
közül ugyan az előbbi nyúlik vissza nagyobb múltra, de 
mára inkább a Microsoft PocketPC terjed el, úgy vélem az 
Európában értékesített gépek többsége ezzel a rendszerrel 
van szerelve. Emellett még léteznek egyéb más operációs 
rendszerek tenyérméretű eszközökre, a legismertebb talán 
a SymbianOS, de a tenyérszámítógépek operációs rendsze- 
rének uralkodója a PocketPC. 

A PDA-kra készült rendszerek mindegyike különös, az aszta- 
li számítógépekétől kicsit eltérő rendszerrel van felszerelve, 
ezek úgynevezett beágyazott (embedded) rendszerek. Ilyen 
beágyazott rendszereket használnak a mobiltelefonokban, 

az úgynevezett smartphone-okban, illetve a tablet pc-k is 
egyfajta beágyazott rendszert futtatnak. Természetesen ezen 
rendszerek között óriási eltérések lehetnek és vannak is. 
Miután a Linux az új évezredben erőteljesebb hódításra 
indult, mint valaha, a fejlődés irányvonalából nem eshettek 
ki a palmtopok sem, így megjelentek az első Linuxok PDA- 
ra. Ezek eleinte sokkal jobban hasonlítottak egy nagy-nagy 
hegesztésre, mintsem kiforrott rendszerre, de valahol min- 
dent el kell kezdeni. A 2000-es évek elején egy nagy, ma 
már önmagában nem létező gyártó piacra dobott egy jópo- 
fa termékcsaládot, az iPAO-et. A Compag annak idején ez- 
Zel a termékkel azt tűzte ki céljául, hogy meghódítsa azo- 
kat az embereket, akik egy notebook-ot túl nagynak, hasz- 
nálatát pedig túl körülményesnek ítélték, viszont egy esz- 
közt, amely könnyedén elfér egy zsebben is praktikusnak 
találtak, így megszületett az eszköz, amely leváltotta 

a jegyzettömböket és a határidőnaplókat. Természetesen 
nem csak a vállalati vezetők és az elfoglalt beosztottaik szí- 
vét sikerült megdobogtatni, hanem azokat a technikai újí- 
tások irányt érzékeny felhasználókat is, akik aztán először 
hobbiból, majd később komoly projektek keretében kezd- 
tek PDA-ra Linuxot fejleszteni. 

Mára eljutottunk oda, hogy palmtopra is egész komoly, 
többé-kevésbé jól használható linuxos rendszerek állnak 
rendelkezésre. Ilyen rendszer az Intimate projektből 


Linuxvilág 





GPE — A beállítások ablak 


kifejlődött Familiar Linux, amely egy kifejezetten 
PDA-kra készült Debian ősből kifejlesztett terjesztés 
(http://familiar.handhelds.org). 

Ahogy az asztali gépekhez készített Linux terjesztések is 
rendelkeznek különböző grafikus környezetekkel, úgy ter- 
mészetesen a PDA-ra készült Familiar Linux is rögtön két 
környezetet is tartalmaz, az egyik egy Ot alapú KDE-vel 
rokon rendszer az Opie, a másik egy GTK-alapú, Gnome 
rokon a GPE. 


Az első lépések 

Mielőtt elkezdenénk a PDA-nkra Linuxot telepíteni ne 
felejtsük el lementeni minden adatunkat, mert a telepítés 
megkezdése után ezeknek búcsút mondhatunk! 

Ha megtörtént a biztonsági mentés, akkor kezdhetjük is 
telepítést. Töltsük le a Familiar weblapjáról a legfrissebb 
telepítőcsomagot és csomagoljuk ki a PC-nk merevleme- 
zére. Ez jelenleg a 0.8.2-es verzió, amit egy tar állomány 











tartalmaz. Jelenleg hat különböző HP-Compag IPAO ké- 
szülékhez érhető el telepítőcsomag, ettől eltérő eszközökre 
való telepítés előtt érdemes a fórumokban és a fejlesztői 
oldalakon körülnézni. 

Amennyiben letöltöttük a telepítőcsomagot, akkor neki is 
foghatunk telepíteni a rendszert. Ennek rögtön több külön- 
böző módjával is próbálkozhatunk. 


A bootloader telepítése 

Mint egy hagyományos asztali PC esetén, itt is telepíteni 
kell valamiféle bootloadert (továbbiakban nevezzük rend- 
szertöltőnek), ami az indításkor a rendszermagot betölti. 
Amennyiben olyan PDA-ra telepítjük a rendszert, amelyen 
PocketPC operációsrendszer fut, akkor mindenképpen 

új rendszertöltőt kell telepíteni, ha viszont egy korábbi 
Linuxról frissítünk, akkor a megfelelő bootloader megléte 
esetén ettől a lépéstől eltekinthetünk. 

Amennyiben telepíteni kell a rendszertöltőt a tenyérgépre, 
akkor többféle adathordozót is választhatunk telepítési 
forrásként. Én ezek közül most a gép saját memóriájából, 
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Ezután már elkezdhetjük a rendszeröltő felülírását, amelyet 
a Flash menü Program menüpontjával indíthatunk el. Itt 
meg kell adni azt a bináris állományt, amely a rendszertöl- 
tőt tartalmazza és indíthatjuk is a memória felülírását. 

Ez a művelet úgy fél percet vehet igénybe. Ha végeztünk, 
akkor az új rendszertöltővel a PDA-t újraindítva a Pocket 
PC operációs rendszerének újra kell indulnia. 


Rendszertelepítés memóriakártyáról 

Ez utóbbi módszer ha lehet, még az előzőnél is sokkal 
egyszerűbb. Mindössze a memóriakártyára kell másolni 

a telepítőcsomag két fenti állományát, majd az előbb leír- 
takhoz teljesen hasonlóan kicserélni a rendszertöltőt. 

Ha kicseréltük a rendszertöltőt, akkor nagyon egyszerűen 
telepíthető az új operációs rendszer. Másoljuk a memóriakár- 
tya gyökérkönyvtárába a reflash.ctl, mdS5sums és jffs2 állomá- 
nyokat, majd a Reset gombbal indítsuk újra a gépet úgy, 
hogy közben a joypad-et lenyomva tartjuk. Újraindulás után, 
amint a boot képernyő megjelenik engedjük fel a joypad-et 
és a hangfelvétel gombjával válasszuk ki a menüből a memó- 
ria ,újraflashelésével" való rend- 
szertelepítést. Ez a folyamat né- 
hány perc alatt lefut, majd a gép 
újraindul és feláll a kiválasztott 
grafikus felület. 

Mind az Opie, mind pedig 

a GPE programcsomag esetén 
néhány alapvető beállítást el 
kell végezni, de pár perc alatt 
üzemkész állapotba hozható 

a PDA. Ha ezzel megvagyunk, 
akkor készen állunk arra, hogy 
birtokba vegyük az új rendszert. 
Mint már említettem a Familiar 
Linux egy Debian alapokra 
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GPE — A naptár alkalmazás 


illetve egy külső CF/S5D/MMC kártyáról való telepítést 
fogom röviden leírni. A többi telepítési mód megtalálható 
a terjesztés hivatalos weboldalán. 


Ehhez először a telepítőkészletből két állományt, 

a BootBlaster".exe-t és a bootldr".bin állományt másoljuk az 
ActiveSync, vagy a SyncCE programok segítésével a PDA-ra, 
majd a Pocket PC beépített állománykezelőjének segítésével 
futtassuk a fenti exe fájlt. Ezzel a segédprogrammal lement- 
hetjük a rendszertöltő jelenlegi állapotát későbbi visszaállí- 
tás céljából, illetve felülírhatjuk azt a letöltött csomaggal. 
Nagyon fontos, hogy ezt a műveletet csak hálózati áramfor- 
rásról végezzük, mert ha véletlenül áramkimaradás lép fel, 
a PDA könnyen érvénytelen memóriaállapotban maradhat 
és akkor csak a szervíz segít rajtunk. 

Ha lementettük a jelenlegi rendszertöltőt, akkor töltsük is 
át a PC-nkre, vagy mentsük valamilyen memóriakártyára. 
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GPE — A gombok beállítása 


építkező rendszer, így azok 

a felhasználók, akik ismerik 

a Debian belső felépítését na- 
gyon könnyen megbarátkoznak 
az új környezettel. A Familiar 
Linux csomagkezelőjét ipkg-nak 
hívják, amelynek használata 
nem meglepő módon nagyon hasonló a Debian alatt meg- 
ismert dpkg és apt csomagkezelőhöz. Az ipkg-n keresztül 
telepíthetünk tehát új csomagokat a rendszerre a megfelelő 
tükörszerver kiválasztása után. 

Amennyiben rendelkezünk a PDA-hoz valamilyen háló- 
zati kártyával, akkor a Debian Linuxnál megszokott 
letc/networkingf/interfaces állományban beállíthatjuk az 
eszközt és innentől kezdve teljes hálózati támogatása van 

a PDA-nak. Támogatott szinte az összes CF kártya alapú 
LAN és WLAN kártya, így ennek kiválasztása minden 
bizonnyal nem jelenthet különösebb problémát. 
Amennyiben nincs ilyen hálózati eszközünk, akkor 

a Familiar weblapján találunk leírást, hogy miként lehet 

a soros, vagy USB csatlakozással az asztali gépünkön 
keresztül hálózatot biztosítani a PDA-nak. 

Miután én először telepítettem és beállítottam a rendszert, 
első dolgom volt a hálózat belövése, majd pedig SSH telepí- 
tése a PDA-ra, mert így SSH-n keresztül lényegesen kényel- 
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Opie — A csomagkezelő 


mesebben lehet a szöveges parancsokat végrehajtani. 
Ugyan kifogástalanul működik a PDA tapogatós billentyű- 
Zete, illetve a kézírás felismerő is, de ezek használata azért 
kicsit körülményes. Főleg parancssori eléréshez. 


A felhasználói programok áttekintése 

A következőkben átnézzük, hogy milyen csomagok is áll- 
nak rendelkezésünkre a Familiar Linuxhoz. Ez alkalommal 
— bár a Gnome közelebb áll a szívemhez - az Opie felülettel 
ismerkedünk meg, mert meglátásom szerint ez kiforrottabb, 
mint a GDPE, bár idővel ez is biztosan hozni fogja a tőle 
elvárható minőséget. 

Az Opite felület egy négy lapból álló alkalmazáskezelővel 

és egy tálcával (taskbar) rendelkezik, minden funkció ezen 
keresztül érhető el. Az alkalmazáskezelő első füle a PIM, 

a Personal Information Manager. Ezen a fülön található meg 
a naptár, a jegyzettömb, névjegyzék és egy teljes értékű 
e-mail kliens. Utóbbi annyira teljes értékű, hogy támogatja 
a POP3 és IMAP protokollokat, méghozzá azon titkosított 
változatát is, kezeli a mappaszerkezeteket és támogatja 

a HTML-levelek megjelenítését is. Őszintén szólva ennek 

a kliensnek a használhatósága engem is meglepett, bőven 
túlszárnyalta minden várakozásomat. A naptár egy teljesen 
szabványos naptárprogram, hasonlóan a névjegyalbumhoz. 
Jegyzeteket két programmal is készíthetünk, az egyik az 
úgynevezett DrawPad, a másik pedig a hagyományos Text 
Editor. A DrawPad mint neve is mutatja inkább egy firka- 
program, ide kézzel, illetve a tollal írott szöveget rögzíthe- 
tünk, míg a Text Editor egy hagyományos szövegszerkesztő 
program, ide az érintőbillentyűzettel, vagy a karakterfelis- 
merővel vihetünk fel szöveget. 

Az Alkalmazások fül alatt találhatóak meg azok a progra- 
mok, amelyeket mi telepítettünk a csomagkezelő progra- 
mon keresztül. Én olyan programokat néztem ki magam- 
nak, amelyeket a mindennapokban az asztali PC-men is 
használok, így telepítésre került az Opie Sheet, ami egy 
Excel vagy ha úgy tetszik OpenOffice.org Calc klón, vala- 
mint az Opie Writer, ami egy OpenOffice Writer klón. 
Telepítettem a PDA-ra egy PDF olvasó csomagot, amely 
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a PDF fájlok 9995-át gond nélkül kezelte. A maradék 190-ért 
pedig a linuxos PDF-olvasóm sem volt oda túlságosan... 

Az Opie tartalmaz egy Kongueror böngészőt, amellyel egy 
tökéletesen használható, teljes értékű webböngészőt kapunk 
a rendszerhez. Mind az Opie, mind a GPE támogatja azt 

a megoldást, hogy 90 fokkal elforgathatjuk a képernyőt, így 
pedig már egész kényelmesen lehet weblapokat nézegetni. 
Eddig azok a programok, amelyeket vártam a PDA-tól, most 
pedig nézzünk pár olyat, amely kisebb meglepetésként ért. 
Található a csomagok között egy Familiar Linuxra optimali- 
zált XMMS, amelyet annyira eltaláltak a fejlesztők, hogy 
szinte tökéletesre sikerült. Használati értéke megegyezik az 
asztali Linuxokra telepíthető XMMS-el. Telepítettem továb- 
bá egy Familiar Linuxos rdesktop-ot, amely programmal 
távoli kliensekkel létesíthetünk asztalkapcsolatot, így akár 

a PDA-ról vezérelhetjük az asztali gépünk grafikus felüle- 
tét. Természetesen a 320x240-es felbontás azért némi korlá- 
tot szab az örömöknek, de szükséghelyzetben ez egy szin- 
tén teljesen használható megoldás, nekem nagyon tetszett. 
Találtam egy Gaim csomagot is, úgy tűnik, hogy eltekintve 
pár gyerekbetegségétől ez a program is teljesen használható 
a mindennapokban, szinte megegyezik az asztali változattal. 
Az összes program közül azonban legjobban a csomagból 
telepíthető mplayer tetszett. Szinte bármilyen videót próbál- 
tunk lejátszani vele, simán működött — persze a nagyon nagy 
felbontású videók némelyike szaggatott picit, de ezt tudjuk 
be a 200MHzZ körüli processzornak. Egy kicsit erősebb vassal 
és egy méretes memóriakártyával kész a nyílt forrású mobil 
médialejátszó. Ennél többet és jobbat kívánni sem lehet. 
Emellett még nagyon jópofa programnak találtam 

a GPSDrive Familiar linuxos változatát, amit azonban 
sajnos hely hiányában már nem volt lehetőségem komo- 
lyabban kipróbálni. Amennyiben működése megközelíti 

az asztali változatét, akkor egy megfelelő GPS eszközzel 
már navigációs rendszerré is alakíthatjuk a PDA-t. 


A beállítások 
A beállítások fül alatt grafikus felületen keresztül bekon- 
figurálhatjuk a teljes tenyérgépes környezetet, így akik 











Opie — Az asztal elforgatva 


nincsenek kibékülve a parancssorral, vagy nem merülnének 
el annak rejtelmeiben, szintén nem kell félniük, hogy ne 
tudnák használni a rendszert. 

Ahogy azt a KDE-ből megszokhattuk, a rendszer megjele- 
nését teljes egészében a saját igényeinkre szabhatjuk, kezd- 
ve a színektől az ablakkereteken át egészen a felületelemek 
megjelenéséig. Nincs az a Pocket PC-s PDA, amelyik ilyen 
tág keretek között szabható testre — bár ezen már nem 
lepődöm meg. 

Szintén testreszabható a PDA-n található nyomógombok 
funkciója, így minden gombhoz egyedi parancsot tudunk 
rendelni. Szintén a beállítások fül alatt találjuk az olyan rend- 
szerparaméterek állítását, mint az idő, nyelv és régió beállítás. 
A fül alatt találjuk a rendszer energiagazdálkodási beállítá- 
sait is. Itt külön szabályokat állíthatunk be tápellátás alatt 
álló módra és akkumulátoros üzemre is. Testre szabhatjuk 

a fényerő erősségét, a háttérvilágítás lekapcsolásának és 

a PDA kikapcsolásának időpontjait. Mindezt a két profilhoz 
teljesen szétválasztva. A fényerő beállítását bízhatjuk az 
automatikára is, ilyenkor az uralkodó fényviszonyoknak 
megfelelően változtatja a PDA a megvilágítás erősségét. 
Szintén a beállítások között találjuk a Familiar Linux grafikus 
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Light off after 
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csomagkezelőjét, ahol csomagok ki- és bepiálásával válogat- 
hatunk a telepített és telepítendő csomagok között. Ezt a cso- 
magkezelőt bármelyik felhasználó könnyedén használhatja. 
Hasonlóan egyszerűen állíthatóak be a hálózati beállítások. 
A rendszer érzékeli az összes elérhető hálózati eszközt és 
felajánlja ezek beállítását. A rendszer támogatja a legújabb 
WLAN eszközöket is, sőt a WEP titkosítást. Sajnos azonban 
WPA titkosításra még nincs lehetőség. Van helyette viszont 
VPN kezelés, méghozzá több protokollon is, így akár IPSec 
kapcsolatot is kiépíthetünk bármely elérhető kiszolgálóval, 
így a vezetéknélküli hálózati forgalmat is tudjuk titkosítani. 


Osszegzés 

Az elmúlt másfél hónapban, mióta a linuxos asszisztensemet 
használom nagyon megszerettem. Használata, filozófiája 
teljesen megegyezik egy hagyományos asztali Linuxéval, 
ha gondba kerültem bármi miatt továbbra is hagyatkozhat- 
tam a naplókra, ha valamit kézzel kellett beállítani, akkor 
parancssorból ezt is pillanatok alatt meg lehetett oldani, 

de még ha véletlen otthon felejtettem a gépet sem kellett 
kétségbe esni, mert SSH-n elérhető volt a gép. 

Amellett pedig, hogy digitális asszisztensnek tökéletes, ta- 
láltam egy más - kissé talán rendhagyó - felhasználási mó- 
dot is. Két CF hálózati kártya beszerzésével a gép bármikor 
egy határozottan kis fogyasztású, de teljes értékű linuxos 
tűzfallá és/vagy útválasztóvá alakítható... Ezen a téren is 
mindent tud, amit elvárhatunk tőle. 

Ha viszont éppen úgy döntök, hogy útra kelek, fogok egy 
nagy CF kártyát és ráteszek egy-két filmet, számtalan mp3- 
at és kész a mobil szórakoztató-központ. 

Természetesen a rendszerben még vannak gyenge pontok, 
vannak gyerekbetegségek, de aki tud kompromisszumot 
kötni, az egy windowsos PDA-val egyenértékű eszközt 
kaphat. Idővel aztán sokkal többre is képessé válhat 

ez a rendszer. Akinek van kedve és megfelelő eszköze, 

az próbálja ki, ennyit szerintem megér. 


Illés Viktor (viktor(willesviktor.hu) 25 éves, 
az Assixo KFT munkatársa 
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Kávéfőzés lépésről lépésre 2-2. rész) 


Az öröklődés, avagy mindig legyen nálad egy angol szótár ha programozol. 


últ hónapban feltelepítettük a Java fejlesztői 
49 környezet 5.0-ás változatát, megírtuk a kötele- 

zőnek számító , Helló világ!" alkalmazást, végül 
egy tehén, egy ló és egy kutya képében megismertük az ob- 
jektum fogalmát. Megtudtuk, hogy az objektum nem más, 
mint egy osztály példánya. Az osztály általános leírást je- 
lent, az objektum ennek az általánosításnak egy megvalósí- 
tása. Szó volt még a tagváltozókról, vagy tulajdonságokról, 
és az ezeken műveletet végző tagfüggvényekről, azaz me- 
tódusokról. Ezek igen közel állnak a hagyományos progra- 
mozási nyelvek változó- és függvényfogalmához. 
Elevenítsük fel az állatok hangját utánzó program 
main(String[1) tagfüggvényt: 


public static void main(String[] args) ( 
Allat tehen - new Allat("múúú"); 
Allat lo - new Allat("nyihaha"); 
Allat kutya - new Allat("vauvau"); 
tehen.szolaljMegO ; 
1o.szolaljMegO ; 
kutya.szolaljMegO ; 


A metódus nyilvános (public), ami azt jelenti, hogy az osztá- 
lyon kívülről elérhető. Továbbá statikus (static), ami azt je- 
lenti, hogy az osztály minden példányára közös, és ezért akár 
példányosítás nélkül is használható. Mivel ez jelenti az alkal- 
mazás belépési pontját, ennek szükségképpen így kell lennie. 
Nem rendelkezik visszatérési értékkel (void), paraméterként 
pedig szövegfüzérek tömbjét kapja (String[1]), mely a pa- 
rancssori paramétereket tartalmazza. A C-hez szokott szem- 
nek talán furcsa, de ennek mindig így kell lennie, nem hozha- 
tó létre belépési pont például int típusú visszatérési értékkel. 
A tagfüggvényben először létrehozunk három változót, me- 
lyek Allat típusúak, és rögtön kezdőértéket is kapnak egy-egy 
példányosítás révén. A tehen, a 10 és a kutya úgynevezett re- 
ferenciák, segítségükkel objektumokra hivatkozhatunk. Az ob- 
jektumok létrehozása az osztály konstruktorának meghívásá- 
val történik, és ezen keresztül állítjuk be a hangjukat. Végül az 
objektumoknak egyesével meghívjuk a szolaljMegO metó- 
dusát, így a képernyőn megjelennek az állatok hangjai. 
Teljhatalmú programozóként állatokat hoztunk létre, és lát- 
tuk, hogy ez jó. Mégis, a Java mögött álló szemlélet azt sugall- 
ja, hogy a megoldás még nem tökéletes. Bármilyen objektum- 
központú alkalmazás fejlesztéséhez modellalkotáson keresz- 
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tül vezet az út. Az általunk használt modellben minden állat 
ugyanazokkal a tulajdonságokkal rendelkezik. Így, ha a meg- 
bízónk tehenek esetében meg szeretné jeleníteni a naponta 
adott tej mennyiségét, már gondban lennénk. Az Allat osz- 
tályt nem bővíthetjük ilyen tulajdonsággal, mert azzal azt 
állítanánk, hogy lovaink és kutyáink is tejtermelő jószágok. 
Kézenfekvő megoldásnak tűnik, hogy képviseljen a tehén 
önálló osztályt. Kérdés viszont, hogy mi legyen a meglévő 
tagváltozókkal és tagfüggvényekkel. Egyszerű, másolás-be- 
illesztés módszerrel kaphatunk egy megoldást, de érezhető, 
hogy ez nem csak csúnya, de rossz hatékonyságú kódot 
eredményező módszert is jelentene. Az objektumközpon- 
túság egyik nagy előnye pedig a nagy mértékű kódújra- 
felhasználás, aminek itt valahogy érvényt kell szerezni. 
Ekkor lép képbe az öröklődés (inheritance). 


A tehén egy állat, de... 

Öröklődésről akkor beszélünk, amikor egy meglévő osztály- 
ból kiterjesztéssel egy új osztályt hozunk létre. Az eredeti, 
vagyis az ősosztály megfelelő láthatóságú elemeit megörökli 
az új, mintha csak saját tulajdonságokról és metódusokról 
lenne szó. Az egyetlen kérdés a láthatóság, de mielőtt elvesz- 
nénk ennek részleteiben, fogadjuk meg azt a bölcsességet, 
mely szerint egy kép többet mond ezer szónál, és rajzoljuk 
le a modellt, mielőtt megvalósítanánk. 

Az UML a Unified Modeling Language rövidítése, és pont 
az, amit a neve is mutat: egységesített modellező nyelv. 
Objektumközpontú problémák leírására szolgál, progra- 
mozási nyelvtől és környezettől függetlenül. A szabvány 
által bevezetett diagrammok segítségével könnyen 
emészthetően fogalmazhatók meg objektumközpontú állí- 
tások, melyek megvalósítása egy-egy programozási nyelv- 
ben már kevés önálló ötletet igénylő kódolási feladatot 
jelent. Nem célom az UML részletes bemutatása, csak 
annyira használom, amennyire segítheti az objektumköz- 
pontúság alapfogalmainak megértését. Lássunk egy UML 
diagrammot az öröklődésre. 

Az ábrán két osztály látható, ezeket három rekeszre osztott 
dobozok jelképezik. Az első rekesz az osztály nevét, a máso- 
dik a tulajdonságokat, a harmadik a műveleteket mutatja. 
Az üres hegyű, folytonos vonalú nyíl mutatja az öröklődést. 
A nyíl irányára több magyarázat is létezik. Szerintem a leg- 
fontosabb annak a ténynek a hangsúlyozása, hogy ennél 

a kapcsolatnál a Tehen osztály hivatkozik az Al lat-ra, és az 
ősosztály semmilyen formában nem értesül az öröklődésről, 
pusztán elszenvedi azt. Az osztályok elemei mögött, egy ket- 











tőspont után azok típusa látha- 
tó. Az elemek nevét pedig egy 
most minket jobban foglalkozta- 
tó jelölés előzi meg. Egyetlen 
különleges karakter, ami a látha- 
tóságot mutatja. A - a nyilvá- 
nos, a - a személyes, a it pedig 

a védett (protected) tagváltozót 
vagy -függvényt jelenti. 

Ez utóbbiról még nem volt szó. 
Nézzük meg, hogyan alakul 

a láthatóság öröklődés esetén. 
Egy nyilvános elem mindenki számára szabadon hozzáfér- 
hető, és ezen az öröklődés nem változtat. Egy személyes 
elem ezzel szemben a teljes elrejtés megvalósítása. Ha szár- 
maztatunk egy osztályt, abban nem lesz látható egy szemé- 
lyesre állított elem. Érezhető, hogy szükség van egy köztes 
megoldásra a láthatóság tekintetében. Ez a védett, ami ide- 
gen osztályoknak továbbra sem elérhető, öröklődés esetén 
pedig megtartja védett tulajdonságát, ezért tetszőleges szá- 
mú öröklés után is látható osztályon belülről. 

Ezért, noha a múlt hónapban személyesre állítottuk az Allat 
osztály hang tagváltozóját, ennek láthatóságát védettre kell 
állítani. Nagyon fontos, hogy ezt nem a szolal jMeg() metó- 
dus érdekében tesszük! A Tehen örökli ezt a metódust, és az 
meghívható egy Tehen típusú objektum esetén. A metódus 
használja a hang változót, de a láthatóság kérdésének eldön- 
tésekor az számít, hogy a művelet hol helyezkedik el, és nem 
az, hogy melyik osztály példányáról van szó. 










$hang: String 


ászolaljMeg(): void 
A 


Tehen 
-tej: int 
HmennyiTej ( ) : 






void 





Ha nem lenne olyan tagfüggvény a Tehen osztályban, 
amely felhasználja a hang tulajdonságot, nem lenne szük- 
ség a védett láthatóságra. Viszont ha egy tehéntől megkér- 
dezzük, hogy hány liter tejet ad, hozzáteszi, hogy ,múúú", 
ezért kell a protected módosító. 

Lássuk a megvalósítást. Két osztályunk, így két forrásállo- 
mányunk lesz. Az első a már múlt hónapban is látott 
Allat. java, azzal a módosítással, hogy a hang protected: 
Je 

$ Ez az osztaly egy allatot ir le. 

s: Tulajdonsaga a hangja. 

: Meg lehet szolaltatni. 

7 

public class Allat ( 


e 

s Az allat hangja. 

47 

protected String hang; 


/ ká 

: Letrehoz egy uj allatot 

: a megadott hanggal. 

§/ 

public Allat(String h) ( 
hang — h; 

s 


/? kal 
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kód 


kód 


4 





Kiirja a kepernyore az 
allat hangjat. 


public void szolaljMegŐ ( 


gé 


kod 


kod 


8 


System.out.printl]n(hang) ; 


e Te 


7 


A program belepesi pontja. 
Letrehoz harom allatot, es 
megszolaltatja oket. 


public static void main(String[] args) ( 


Tehen tehen - new Tehen("múúú", 20); 
Allat lo - new Allat("nyihaha"); 
Allat kutya - new Allat("vauvau") ; 
tehen.szolaljMegO ; 

tehen.mennyiTejO ; 

1o.szolaljMegO ; 

kutya.szolaljMegO ; 


Következzen a Tehen.java állomány: 


Je 


: Ez az osztaly egy tehenet ir le 


: Tulajdonsaga a tej mennyisege, amit egy nap ad. 


s Ezt ki lehet iratni a kepernyore. 
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public class Tehen extends Allat ( 


Jer 
s: A naponta adott tej mennyisege. 


1/ 


private int tej; 


Je 
s: Letrehoz egy uj tehenet a megadott 
s hanggal, és napi tej mennyiseggel 
97 
public Tehen(String h, int t) ( 
super (h) ; 
tej — t; 


Je 

" Kiirja a kepernyore a napi 

" tej mennyiseget 

97 

public void mennyiTrejO 1 
System.out.println(tej 4 " liter, 
mm" 4 hang); 


A fordítás és futtatás a megszokott módon történik: 
$ javac Allat.java Tehen. java 
$ java Allat 
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Az új osztály bevezetése akkor nyer értelmet, ha használatba 
is vesszük, így a program belépési pontja is változott. Tehenet 
immár a Tehen osztály példányosításával hozunk létre. 

Az öröklés miatt meghívhatjuk az ősosztályban szereplő 
szolaljMegO mellett a kibővítés révén nyert mennyiTejO 
metódust is. Így a képernyőn az alábbi kimenet látható: 
múúú 

20 liter, múúú 

nyihaha 

vauvau 


Időzzünk el még egy keveset az öröklődés példaképét jelen- 
tő Tehen osztály elemzésével. Magának a kapcsolatnak a ki- 
fejezése nagyon egyszerű, csupán az osztály fejében kell ezt 
jeleznünk az extends (kiterjeszt) kulcsszó segítségével. Az 
egyetlen kérdés az, hogy pontosan mi is történik a példányo- 
sításkor meghívódó konstruktorokkal. Nyilvánvalóan akkor 
hasznos az öröklődés, ha a meglévő metódusokat nem kell 
újraírni, így a tagváltozókat értékkel ellátó konstruktort sem. 
Lehet valahogy hivatkozni az ős kosntruktorára? 

A válasz igen, de nem magától értetődő, hogy hogyan. 

A konstruktor különleges függvény abban a tekintetben, 
hogy minden más metódussal ellentétben nem jelezzük 

a visszatérési értékét, hiszen meghívásakor objektum 
készül, amit viszont nem a függvény ad. Pontosan ezért 
különleges bánásmódot igényel. Meghívása a super hivat- 
kozással történik, melyet az ős konstruktorának megfelelően 
kell paraméterezni. 

Két dolgot hangsúlyoznék ezzel kapcsolatban. Ha az ősosz- 
tály tartalmazna paraméter nélküli konstruktort, és a szár- 
maztatott osztály konstruktorában nem lenne super hívás, 
akkor a származtatott osztály példányosításakor először ön- 
működően meghívódna az ősosztály kosntruktora. Továbbá 
nagyon fontos, hogy ha így hivatkozunk egy ősosztálybeli 
konstruktorra, a super hívásnak a legelső műveletnek kell 
lennie, egyébként a fordító hibát is jelez. 

A mennyiTejO metódusban a kiíratásnál a -- operátor 
segítségével fűzzük eggyé a szövegfüzéreket. Ez egy igen 
kényelmes, és könnyen olvasható megoldást jelent. Ugyan- 
akkor ez azt is jelenti, hogy a -- több értelemmel is bír, hi- 
szen számok aritmetikai összeadása mellett String típusú 
objektumok összetfűzését is lehetővé teszi. Ez egy beépített 
megoldás, amit az objektumközpontúság szakzsargonjával 
élve operátor túlterhelésnek hívunk (operator over1oad). 
Jó tudni, hogy egyes nyelvek, például a C4-- ezt a progra- 
mozó számára is lehetővé teszik. Jelen helyzetre lefordítva, 
ha azt mondanánk, hogy két tehén egyenlősége akkor telje- 
sül, ha ugyanannyi tejet adnak, túlterhelhetnénk az -—— ope- 
rátort, hogy kényelmesen hasonlítsunk össze két Tehen tí- 
pusú objektumot. Ugyanez Java-ban hatékonysági okokból 
nem megvalósítható. 

Mindezek alapján már bátran belegondolhatunk, mi is 

az ami miatt hasznos az objektumközpontú tervezés. 

Egy kellően átgondolt modell segítségével olyan alkal- 
mazást építhetünk, ami nem csak könnyebben átlátható, 

de egyszerűen bővíthető is. A sorozattal kapcsolatban vá- 
rom az észrevételeket, javaslatokat. Következő hónapban 
az interfészek lesznek terítéken. 


Fülöp Balázs (bigwig42.ogmail.com) 














Számítógép-hálózatok (19. rész) 
Az Internet hálózati rétege, az IP protokoll, 
címzések és alhálózatok 


A sorozat elmúlt néhány részében áttekintettük, mi is a feladata, illetve miként 

is működik a hálózati réteg. Most egy konkrét megvalósítást veszünk szemügyre, 
amelyen megnézzük, miként is mennek a dolgok a gyakorlatban. Ebben a hónap- 
ban tehát témánk tehát az Internet hálózati rétege és annak protokolljai. 
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hálózati réteg feladata nem más, mint a szállítási 
rétegtől kapott adatokat eljuttassa a címzettig. 


Mindezt úgy kell megvalósítania, hogy a szállítási 
réteg szempontjából teljesen mindegy legyen, hogy a cél 
a forrással egy hálózatban van-e, vagy sem. Magyarul 
a szállítási réteg csak az elküldendő adatot és a cél címét 
adja meg, minden más a hálózati rétegre van bízva. 
Az Interneten zajló kommunikáció tehát a következőképp 


zajlik (1. ábra): a szállítási réteg (transport layer) kap egy 
adatfolyamot az alkalmazási rétegtől (application layer). 
Ezt az adatfolyamot blokkokra, úgynevezett datagramok- 
ra bontja, majd átadja a hálózati rétegnek (network layer), 
amely gondoskodik azok célbajuttatásáról. Látható, hogy 
az Internet felépítése nem követi az OSI modellt, amelyre 
sorozatunkat is építettük. A fizikai és az adatkapcsolati 
réteg ugyanis össze van vonva, továbbá hiányzik 

a viszont és a megjelenítési réteg (ezek egyes feladatai 

a szállítási, mások pedig az alkalmazási rétegben kerül- 
nek megvalósításra). 














1. ábra Az Internet rétegei. Ez a felépítés némiképp eltér 
az OSI modelltől, hiszen hiányzik az adatkapcsolati, a viszony 
és a megjelenési réteg. 





A 2. ábrán láthatjuk az Internet protokolljainak egymáshoz Az OSI referencia- 

való viszonyát. Ezek közül a mezei felhasználók csak az modot CEE EKB ÉZST EE 
alkalmazás rétegbeli protokollokkal kerülnek közelebbi 

kapcsolatba, mint például az FTP-vel vagy az ábrán ugyan 


fel nem tüntetett, ám manapság leggyakrabban használt drink 
HTTP-vel, amely a weboldalak lehívásában játszik szerepet. 

A TCP (Transmission Control Protocol) két gép közötti 
megbízható bájtfolyam alapú kommunikáció kialakítására 
alkalmas protokoll, az UDP (User Datagram Protocol) pedig 
ennek megbízhatatlan , párja". Ezek a szállítási réteg proto- 
kolljai, a későbbiekben részletesen is foglalkozunk velük. 


Viszony réteg 








Transzport réteg TCP UDP 



































; € Hálózati réteg Útválasztási protokollok 
Mi most azonban még maradunk a hálózati rétegnél, 
és azok protokolljainál. Közülük a legjelentősebb az IP teltek 
(Internet Protocol), amely a gépek közötti adatátvitelt réteg 
végzi. Fontosak még a vezérlőprotokollok, mint például Meghatározatlan 
az ICMP (Internet Control Message Protocol), vagy 
a logikailag az adatkapcsolati és a hálózati réteg határán 
elhelyezkedő ARP és RARP. 2. ábra Az Internet protokolljai 
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3. ábra Az IP csomagok fejlécének felépítése 


Az ennél mélyebb szinten lévő dolgokról az Internet szab- 
ványa már semmit sem mond. Itt az adott LAN-ra van bíz- 
va, hogy miként valósítja meg a benne lévő gépek közötti 
adatátvitelt. Az Internetbe tehát ugyanúgy beköthetünk 
például egy vezérjeles gyűrűt, mint egy Ethernet hálózatot. 
Most pedig vegyük kicsit részletesebben is szemügyre az 
Internet hálózati rétegének protokolljait! 


Az IP (Internet Protocol) 

A szállítási réteg által előállított TCP és UDP datagramok IP 
csomagok belsejében utaznak a világhálón. Egy IP csomag 
két részből áll: magából a szállított adatból és egy fejlécből. 
A fejléc szerkezetét láthatjuk a 3. ábrán. 

Amikor két különböző számítógép, például egy SPARC és 
egy Pentium processzorral felszerelt masina bitsorozatokat 
szeretne egymással cserélni, akkor rögtön félreértések 
adódnak. A Pentium ugyanis alsó vég szerint tárolja a bite- 
ket, azaz mindig a legkisebb helyiértékű bitet küldi elsőnek. 
A SPARC-nál ez pont fordítva történik. Ha a Pentium azt 
akarja mondani partnerének, hogy , 41", akkor ő az 100101 
bitsorozatot fogja küldeni, amit a SPARC 37-nek fog értel- 
mezni. Ezért először meg kell egyezni abban, hogy a biteket 
alsó- vagy felső vég szerint továbbítjuk. Az IP protokoll fel- 
ső vég szerint tárolja az adatokat a fejlécében. (Ezért ha 
Pentium processzorra írunk hálózati alkalmazást, figyel- 
nünk kell arra, hogy a cél címét először átalakítsuk felsővé- 
gűre, majd csak utána adjuk át a szállítási rétegnek). 

Most nézzük sorra, mi mit is jelent a fejlécben. A verzió érte- 
lemszerűen az IP protokoll verzióját adja meg, pontosabban 
azt, hogy az adott csomag az IP protokoll mely változatához 
tartozik. Az IHL mező a fejléc utolsó részének, az opciók mé- 
retét adja meg. Erre azért van szükség, mert ennek a mező- 
nek nincs kötött mérete, hossza csomagonként változó lehet. 
Mindenesetre 60 bájtnál nagyobb nem lehet. 

A szolgáltatás típusa (type of service) eredetileg arra hiva- 
tott, hogy az alhálózat számára hordozzon információkat 
a továbbításánál felmerülő kérdésekkel kapcsolatban. 
Ilyen lehet például a csomag prioritása (erre az IP 8 szin- 
tet biztosít), vagy például az, hogy gyorsan, vagy inkább 
biztonságosan kívánjuk a csomagot céljához eljuttatni. 
Példaként most is felhozhatjuk az előző részben leírtakat: 
egy hálózaton keresztüli videónézésnél fontosabb, hogy 

a csomagok sebessége ne lassuljon le, ugyanakkor egy fájl 
átvitelekor inkább az a jobb, ha a csomagok sértetlenül 
érkeznek meg. Az igazsághoz azonban az is hozzátartozik, 
hogy az útválasztók többsége nem foglalkozik az itt meg- 
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adott paraméterekkel. Ez gyakorlatilag azt jelenti, 

hogy bármit is írunk erre a mezőre, nem lesz kihatással 

a csomagunk célbajutásának módjára. 

A teljes hossz (total length) az egész csomag méretét 

adja meg, beleértve a fejlécet és a szállított adatokat is. 
Mivel ez egy két bájtos mező, ebből következően egy 
csomag nem haladhatja meg a 65535 bájtot (egy bájt 
híján 64 kilobájt). Ez első hallásra soknak tűnhet, 

de a sávszélesség növekedésével előbb-utóbb kevésnek 
számítanak majd, és nem lesz gazdaságos ilyen , kis" 
csomagmérettel dolgozni. 

Az útválasztók időnként feldarabolják a datagramokat. 
Az azonosítás (identification) mező adja meg, hogy az 
adott csomag melyik datagram része. A jelzők (flags) há- 
rom bitből áll, amelyek közül az első kihasználatlan, a má- 
sodik az úgynevezett DF (Dont Fragment - ne darabold!) 
bit. Ez megtiltja az útválasztók számára, hogy az adott 
csomagot több részre szabdalják. Ezt a bitet akkor szokás 
beállítani, amikor a célállomás valami oknál fogva nem 
képes több darabból összeállítani az eredeti datagramot. 
A darabolás megtiltásának azonban ára van: elképzelhető, 
hogy a csomag egy darabban csak kerülőúton keresztül 
érhet célba. A jelzők mező harmadik bitje az MF (More 
Fragments - még több darab). Ez azt jelzi a célállomás 
számára, hogy a datagram még nem ért át teljesen, újabb 
darabokra kell számítani. 

Ahhoz, hogy a gép rekonstruálhassa a számára küldött 
datagramot, a darabok sorrendjét is ismernie kell (hiszen 
semmi sem garantálja, hogy a csomagok útnak indulásuk 
sorrendjében érkeznek meg). Erre szolgál a darabeltolás 
(fragment offset) mező, amely megmondja, az adott darab 
mely részét képezi a datagramnak. Az utolsó darabot leszá- 
mítva ennek a mezőnek az értéke mindig a 8 valamely 
egész számú többszöröse. Mivel az egész mező összesen 

13 bájt méretű, ezért egy datagramot 8192 darabnál többre 
nem oszthatunk. 

Az alhálózaton örökre bolyongásra ítélt csomagok elkerülé- 
sére szolgál az élettartam (time to live) mező, amely meg- 
mondja, még mennyi ideig élhet az adott csomag. Ha ez az 
érték nullára csökken, az útválasztók a csomagot eldobják. 
A szabvány szerint az élettartamot másodpercben kell meg- 
adni, de a gyakorlatban inkább ugrás-számban határozzák 
meg, azaz minden útbaeső útválasztó eggyel csökkenti 

a mező értékét. Ha egy csomag ideje lejár, az útválasztó, 
amelyik a csomagok eldobta, egy értesítőt küld a feladónak 
a történtekről. 

A protokoll rész arról árulkodik, hogy a csomag milyen 
típusú datagramot hordoz, például TCP, UDP, stb. Ez a cél- 
állomás számára fontos, hiszen annak hálózati rétege innen 
tudja, hogy mely szállítási réteghez tartozó folyamatnak 
kell a beérkező adatokat átadnia. 

A fejlécellenőrző összeg (header checksum) értelemszerűen 

a fejléc sértetlenségének megállapítására szolgál. Mivel 

a fejléc élettartam mezője minden ugrásnál változik, ezért 
az útválasztóknak a csomag továbbítása előtt az ellenőrző 
összeges újra ki kell számolniuk. 

A forrás és a cél címe (source/destination address) meg- 
mondja, ki a címzett és ki a feladó. Az Interneten a gépek 
úgynevezett IP címekkel vannak azonosítva, erre mindjárt 
részletesen is kitérünk. 
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4. ábra A traceroute parancs segítségével feltérképezhetjük, hogy 
milyen útválasztókon keresztül érhetjük el a megadott célállomást 


Az opciók (options) rész eredetileg arra szolgált, hogy ké- 
sőbb jelentősebb változtatások nélkül bővíthessék az IP 
protokoll által nyújtott szolgáltatásokat. Mint már emlí- 
tettük, ez a rész változó méretű, lehet teljesen üres is 

(de 40 bájtál semmiképp sem több), így csak akkor kell 
több helyet lefoglalni a fejrész számára, ha az opció mező 
valóban felhasználásra is kerül. 

Az IP tervezése óta öt dologgal bővítették ki az IP 
fejlécét, illetve pontosabban az opció mezőt. Ezek 

közül az első a biztonság, amellyel meghatározhatjuk 

a csomagban szállított datagram titkosságát. Az eredeti 
célkitűzés az volt, hogy bizonyos titkosnak számító 
adatokat csak meghatározott útválasztókon keresztül 
lehessen továbbítani. Ezzel elkerülhető például az, 

hogy katonai titkokat hordozó csomagjaink áthaladjanak 
ellenséges (vagy legalábbis nem túl barátságos) országok 
útválasztóin. A ma használatban lévő útválasztók nem 
támogatják ezt a szolgáltatást. 

Egy másik opció a szigorú forrás általi forgalomirányítás, 
amikor a datagramot küldő gép határozza meg, hogy 

a csomagnak milyen útvonalon kell eljutnia a célállomá- 
sáig. Ilyenkor az opciórészben meg kell adni a pontos 
útvonalat (útválasztók IP címeinek sorozatát), amelyen 

a csomagnak haladnia kell. Ennek egy ,enyhébb" válto- 
zata a laza forrás általi forgalomirányítás, amikor csak azok- 
nak az útválasztóknak a címeit mondjuk meg, amelyeken 
a csomagnak biztosan át kell haladnia. Ezzel az opcióval 
lehetőség nyílik arra, hogy csomagjainkkal elkerüljünk 
bizonyos térségeket. 

A negyedik opció az útvonal feljegyzése. Ennek hatására 
az útválasztók az átmenő csomagok opció mezejébe beírják 
saját címüket, így a célállomás rekonstruálhatja, milyen 
útvonalon érkeztek meg hozzá a csomagok. A traceroute pa- 
rancs (4. ábra) is hasonló szolgáltatást nyújt, segítségével ki- 
listázhatjuk, milyen útválasztókon kell keresztülmennünk 
ahhoz, hogy elérjünk egy megadott gépet. A különbség csak 
az, hogy a traceroute nem használja az útvonal feljegyzése 
opciót, teljesen más elven működik. Az az igazság, hogy 
nem is lehet ezt a módszert erre a célra használni, ugyanis 
ezt még akkor találták ki, amikor az Internet mérete még 
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5. ábra Egy csomag belső felépítése 


jóval kisebb volt, és 9 ugráson belül bárhova el lehetett jutni. 
Ma már más a helyzet. A 4. ábrán látható, hogy például egy 
népszerű amerikai keresőportál eléréséhez a csomagoknak 
legalább 17 útválasztón kell keresztülverekedniük magukat. 
Ilyen hosszú útvonal pedig már aligha fér el 40 bájton. 

A traceroute inkább azt használja ki, hogy az útválasztók 
visszajeleznek, ha egy általunk küldött csomagnak lejár az 
életideje, és el kell dobniuk. Így kiküld különböző ám kis 
élettartamú csomagokat (amelyek annyi idő alatt biztosan 
nem jutnak el céljukig), és amelyik útválasztó visszajelzi 

a csomag halálhírét, az biztos része a csomag útvonalának. 
Végezetül megemlítjük még az utolsó opciót is, az idő- 
bélyeget, amely szinte teljesen megegyezik az előzővel, 
csak azzal a különbséggel, hogy az útválasztók nem csak 
az IP címüket, hanem a csomag beérkezésének idejét is 
feljegyzi. Ezáltal pontosabb képet kaphatunk a csomagok 
alhálózatbeli terjedéséről. 


Az ICMP (Internet Control Message Protocol) 

Az IP-n kívül más protokollokat is használ az Internet 
hálózati rétege. Ezek közül az egyik legfontosabb az 
ICMP, amelynek két funkciója van. Először is lehetővé 
teszi hogy mérhessük a hálózat bizonyos tulajdonságait. 
Másodszor lehetőséget biztosít az útválasztók számára, 
hogy jelezzék a csomag feladójának, ha valami váratlan 
esemény következik be. 

Ilyen váratlan esemény lehet például az, ha az útválasztó 
nem találja magát a célt, vagy hibás fejlécű IP csomagot 
kapott. Az ICMP üzenetek másik gyakori felhasználása az, 
amikor egy gép életjeleit kívánjuk megállapítani (például 
a ping parancs segítségével). Ilyenkor egy úgynevezett 
ECHO REOUEST üzenetet küldünk, amelyre a gép 

— amennyiben életben van - egy ECHO REPLY ICMP 
üzenettel válaszol. 


Címzés az Interneten 

Ahhoz, hogy a hálózati réteg megtalálja a csomagok cél- 
állomását, minden gépnek (és útválasztók) rendelkeznie 
kell egy vagy több egyedi azonosítóval. Az Interneten ez 
az azonosító az IP cím, amely egy 32 bites összeg. 
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6. ábra Az IP címosztályok 
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7. ábra Alhálózatok egy lehetséges felosztása 


Ezt a számot általában bájtonként decimálisan, ponton- 
ként elválasztva szokás megadni, például: 195.38.96.96. 

A valamivel több mint 4 milliárd lehetséges IP címet öt 
csoportra oszthatjuk (6. ábra). Ezek közül az első három 
osztály (A, B és C) IP címei azonosítanak gépeket. Az egy 
hálózatban lévő hosztok hálózati címeinek tehát meg kell 
egyezniük. A D osztályba tartozó címek a többesküldésre 
(multicasting) , az E-beli címek pedig későbbi felhasználásra 
vannak fenntartva. 

Hogy egy IP cím melyik osztályba tartozik, azt az 

első pár bitje adja meg. Az A osztályú címek például 
mindig 0-val kezdődnek, ez azt jelenti, hogy az 1.0.0.0 

— 127.255.255.255 tartományon belül minden IP cím 

A típusú. Az A, B és C osztályok közötti különbség 

az, hogy mennyi bitet használnak magának a hálózat, 

és mennyi bitet a hálózatban lévő egyes gépek azono- 
sítására. Az A osztály esetében összesen 126 hálózatot 
lehet megkülönböztetni, viszont ezek a hálózatok akár 
16 millió gépből is állhatnak. (Persze ez azt is jelenti, 
hogy összesen csak 126 darab A osztályú címcsoport 
osztható ki). Ezzel szemben a C típusú címek már 

21 bitet használnak a hálózaton azonosítására, viszont 
csak 256 (gyakorlatban 254, lásd később) darab gépet 
tartalmazhatnak. 

Vannak speciális célra fenntartott IP címek is, amelyek nem 
oszthatók ki a gépek számára. Ilyen például a csupa egyes 
bitből álló (255.255.255.255), amely az adatszórást teszi le- 
hetővé a helyi hálózaton. Azok az IP címek, amelyeknek 
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a hálózati része csupa nullából áll, mindig az aktuális háló- 
zatra vonatkoznak. A 127." ."." tartomány szintén nem oszt- 
ható ki, ez az úgynevezett visszacsatolás (loopback), ame- 
lyeken keresztül a gép saját magát ,érheti el". Próbáljuk 
csak megpingelni bármelyik 127-el kezdődő IP címet, min- 
dig a saját gépünk fog válaszolni. A visszacsatolásnak pél- 
dául akkor vehetjük hasznát, ha ki szeretnénk próbálni egy 
hálózati alkalmazást anélkül, hogy egy második gépet is 
igénybe vennénk. 


Alhálózatok 


Már említettük, hogy az egy hálózatba tartozó gépek 
hálózati címeiknek meg kell egyezniük. Egy B osztályú 
címtartományt birtokló szervezet esetében azonban nincs 
mind a 65 ezer gép egy fizikai hálózaton. Egy egyetem 
esetében például külön hálózatot képezhetnek az egyes 
géptermek, illetve a tanszékek számítógépei, és ezek 

a különálló LAN-ok hidak segítségével vannak össze- 
kapcsolva. Felmerül a kérdés, hogy akkor miként 

osszuk ki az IP címeket? 

Kézenfekvő megoldás lehet az, hogy visszaadjuk a B 
címtartományunkat, és kérünk annyi C osztályút, ahány 
hálózatunk van. Ezzel azonban több problémánk adódna, 
például jelentősen megnehezülne a hálózat menedzselése. 
A megoldás az alhálózatok (subnets) létrehozásában rejlik. 
(Az elnevezés sajnos megtévesztő. Ezeknek az alhálóza- 
toknak semmi köze az útválasztókból álló kommunikációs 
alhálózathoz). 

Az alhálózatok kialakításához az IP címek gépek azonosítá- 
sára szolgáló 16 bitjéből leválasztunk valamennyit, amelyek 
az egyes alhálózatokat fogják megadni. A 7. ábrán láthatunk 
is erre egy példát. Tegyük fel, hogy a 131.107."." B típusú IP 
címtartománnyal rendelkezünk. Itt az utolsó két bájt azono- 
sítja a gépeket. Az ábrán ebből 8 bitet az egyes alhálózatok 
azonosítására áldozunk. Ekkor összesen 254 alhálózatunk 
lehet, és mindegyikben 254 gép helyezhető el. 

Fontos, hogy ez a felosztás kívülről (egy másik hálózatból) 
nem látszik. Az ottani szemlélődő úgy látja, hogy nekünk 
csak egyetlen nagy hálózatunk van. A belső útválasztóink 
azonban ismerik a hálózatunk belső felépítését, és tudják, 
melyik gép merre található. Pontosabban csak azt kell tud- 
niuk, hogy az egyes alhálózatok merre találhatóak. Az úgy- 
nevezett alhálózati maszk segítségével ugyanis az útválasz- 
tók az IP címből ki tudják számolni, hogy melyik alhálózat 
felé is kell terelni a csomagot. Az alhálózati maszk egy 
olyan 32 bites szám, amellyel ha össze ÉS-eljük az IP cím- 
mel, akkor kinullázódik annak a gépet azonosító része. 

Az előző példánknál a netmask minden bizonnyal 

a 27 darab egyesből, és 8 darab nullából (255.255.255.0) 
lenne. Ha beérkezik egy csomag, amely a 131.107.12.2-es 
című gépnek szól, akkor az útválasztó az alhálózati maszk- 
kal ,összeéselve" megkapja, hogy a kérdéses gép melyik 
alhálózatban is található (jelen esetben a végeredmény 

a 131.107.12.0 lesz). 

A következő részben megismerkedünk az Internet más 
fontos, szintén a hálózati rétegbe tartozó protokolljaival, 
például az ARP-al és a RARP-al. 


Garzó András 
garzoand inter ware.hu 











L"Intranet Originale 


Azt hiszed, nem tudsz egy teljes közösségnek helyt adni nagyjából 64 k-ban? 


Próbálj ki egy elektronikus hirdetőtábla rendszert! 


ég szép, hogy nem grafikus, de színek azért 
HA vannak, mon ami. Miért? Ugyan már, Francois, 
hadd nosztalgiázzak egy kicsit! Amikor láttam, 
hogy ennek a lapszámnak az intranetek adják a témáját, 
elgondolkoztam ezen az egész intranet-dolgon, ami 
tulajdonképpen egy belső hálózat, egy apró magán- 
univerzum, amihez, ha úgy akarjuk, csak néhányan 
férhetnek hozzá. Általában azt gondoljuk, hogy ilyesmit 
inkább vállalatok és hasonló szervezetek használnak, 
de például az azonos hobbi iránt érdeklődők számára 
is hasznos lehet. Amikor intranetekről beszélünk, 
mostanában inkább webes kapcsolatkezelő rendszerekre 
és portálokra gondolunk. 
Ouwoi? Szöveges a képernyő? Tény. Az intranetek sokkal 
korábban kialakultak, mint hogy internetezni kezdtünk, 
mon ami, és a kapcsolattartás bizony szöveges felületen tör- 
tént. Mon Dieu, elbeszélgetjük az időt! Már meg is érkeztek 
a vendégeink! Üdvözöllek benneteket, mes amis, helyezzé- 
tek magatokat kényelembe, amíg Francois megtölti pohara- 
tokat! A borospincébe, Francois! Hozd fel azt a 2003-as 
Coastal Sauvignon Blanc-t. Vite! 
Éppen az eredeti intranetekről meséltem Francois-nak, 
mes amis. Éppen csak kiléptem a tinédzserkorból, amikor 
üzembe helyeztem egy ilyen intranetet a Commodore 64- 
esemen. Úgy hívták őket, hogy elektronikus hirdetőtáb- 
lák, röviden BBS-ek (bulletin board system). Lényegé- 
ben annak idején saját BBS-t írtam és tartottam fenn. 
Egyetlen telefonvonal tartozott hozzá, vagyis egyszerre 
csak egy felhasználó használhatta. Nem tartozott semmi- 
lyen hálózatba, de azért intranet volt, és fennállása 
csúcsán 40-50-en is használták. A régi szép idők emlé- 
kének adóztam, amikor BBS programokból állítottam 
össze mai menünket. 
Sokan gondolhatják, hogy ma már minden grafikus, 
és senki nem dolgozik szöveges megjelenésű BBS prog- 
ramokkal. A valóság azonban az, hogy számos BBS 
van még jelenleg is üzemben, és a szükséges programok 
fejlesztése jelenleg is folyik. 
Első fogásunk Bryan Burns NexusChatje. A NexusChat, 
más néven NChat egy kiváló, BBS-es stílusú program, 
különféle felhasználói szintekkel, több szobával, magán 
és csoportos csevegési lehetőséggel, e-mail küldéssel, 
üzem közben módosítható beállításokkal, súgóval 
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1. ábra Telnettel csatlakozva a NexusChat kapujára ezt 
a bejelentkezési képernyőt kapjuk 


és számtalan további szolgáltatással. A NexusChat futtatá- 
sához nincs szükség root jogosultságokra, sőt, telepítése 


is elvégezhető ezek nélkül. Első lépésként hozzuk létre 
azt a könyvtárat, ahova telepíteni szeretnénk a csevegési 


kiszolgálót. Én például létrehoztam egy nexuschat könyv- 
tárat a saját kezdőkönyvtáramban. A következő lépés 
a forráscsomag kibontása: 


tar -xzvf nchat-3.31.tar.gz 


cd nchat-3.31 
./setup.sh 


A megválaszolandó kérdések meglehetősen egyszerűek, 
és néhány kivételtől eltekintve az alapértékeket is nyu- 
godtan elfogadhatjuk. Amikor a parancsfájl rákérdez, 


hogy hová szeretnénk telepíteni a bináris fájlokat, adjuk 
meg a korábban létrehozott könyvtár nevét. Az alap adat- 
könyvtár (alapértéke /home/nchat/etc) ezután a telepítési 
könyvtár alkönyvtára legyen. A következő kérdés a kapuk 
száma. Ez határozza meg, hogy egyszerre hányan csatla- 


kozhatnak a csevegési kiszolgálóhoz, alapértéke 15. Miután 
erre az utolsó kérdésre is válaszoltunk, adjuk ki a make pa- 


rancsot. A fordítás mindössze néhány másodperc, melyet 
követően létre kell hoznunk a felhasználói adatbázist. 
Alapesetben 999 felhasználót adhatunk meg. 


2005. július 
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Ennyi, az insta11 parancs elmarad. A végső lépés az etc 
könyvtár kézi átmozgatása végső helyére, illetve ezt kell 
tennünk az nchat és az userdb bináris fájlokkal is. Mivel 
nálam a kiszolgáló a /home/marcel/nexuschat könyvtárból 
fut, a következő parancsokat adtam ki: 


mv etc /home/marcel/nexuschat 
mv nchat /home/marcel/nexuschat 
mv userdb /home/marcel/nexuschat 


Lépjünk át a NexusChat könyvtárába, majd a userdb -z -s 
999 paranccsal készítsük elő a felhasználói adatbázist. Létre 
kell hoznunk a 000 felhasználót is, akinek a root jelszót kell 
adnunk. Az alapesetben a 4000-es kapun futó kiszolgáló 
elindítása a /elérési út/nchat paranccsal történik. Most 
egy másik terminálról a 000 felhasználóval jelentkezzünk 
be a csevegési kiszolgálóra: 


telnet kiszolgáló 4000 


A bejelentkezés után első teendőnk a jelszavunk megvál- 
toztatása. Ezt a /passwd titok paranccsal tehetjük meg, 
ahol a titok az új jelszó. Csatlakozás után, csevegés közben 
számos további parancs áll rendelkezésünkre, ezek a jelszó- 


változtatás parancsához hasonlóan egy perjellel kezdődnek. 


A parancsok listáját a /? utasítással kérhetjük le. Ha valami 
miatt nem látjuk, amit begépelünk, a /echo parancsot kell 
használnunk. 

Ettől a ponttól kezdve vendégek bejelentkezésére is 

van mód; a vendégként való belépéshez elég lenyomni 
az ENTERT. A vendégek a NEW paranccsal kezdeményez- 
hetik normál felhasználóként való bejegyzésüket, ám 
bejelentkezni csak azt követően tudnak, hogy a rendszer 
gazdája jóváhagyta a bejegyzést. Ezen a ponton módjuk 
nyílik adataik megváltoztatására, illetve csevegésre, bár 
csak egy korlátozott parancskészlettel. A rendszergazda, 
vagyis az nchat programot futtató személy az állandó 
felhasználók hozzáadására és az önállóan bejegyzett 
felhasználók engedélyezésére a felhasználószerkesztőt 
használhatja, mely a /ue username paranccsal indítható 
el. A művelet a parancssorból is elvégezhető, mégpedig 
a másik korábban telepített bináris fájllal, a userdb-vel. 
Ha tehát a NexusChat könyvtárából szeretnénk felhasz- 


nálót hozzáadni, a következő parancsot kell használnunk: 


./userdb -a user -u -] 003 -h Francois -p 123 
5-t 3600 


A kapcsolók jelentése a következő: 


-a — felhasználói fiókot adunk hozzá 
(létezik rendszergazdai is) 
-u — frissítjük az adatbázist 
-1 -— a felhasználó sorszáma 003 
-h -— a felhasználó neve Francois 
-p - a hozzárendelt jelszó 123 
-t — a kapcsolatok időtúllépési ideje 3600 másodperc 


Ha kapcsolók nélkül csupán a userdb parancsot ad- 
juk ki, akkor a rendelkezésünkre álló kapcsolók listája 
jelenik meg. 
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2. ábra A bbs100 elektronikus hirdetőtábla rendszer 
csevegőszobáinak és naptárainak fenntartásához mindössze 
néhány kB memóriára van szükség 


Már említettem, hogy az alapértelmezett kapuszám 

a 4000-es. Ezt és néhány további beállítást a etc/nchatrc 
fájl átírásával lehet módosítani. Érdemes például 

a chat. name-et az általunk kívántra, például BBS-ünk 
nevére módosítani. Bizonyos beállítások, mint például 
az ask ansi - true megjegyzésbe vannak téve. 

Bár a legtöbb terminál gond nélkül kezeli az ANSI 
színeket, ha gondoljuk, akkor bejelentkezéskor kínáljuk 
fel a felhasználóknak a választás lehetőségét. 

Az etc könyvtárban további érdekes fájlokat is találunk. 
Az nc login fájl például azt határozza meg, hogy a felhasz- 
nálók mit látnak bejelentkezéskor. Hasonló célt szolgál az 
nc ansi login és az nc motd (napi üzenet) is. 

A NexusChat szórakoztató kiegészítő, könnyű használ- 
ni, felügyelete csak kevés tennivalóval jár. Rendkívül 
rugalmas, a felhasználók és a csevegőszobák létreho- 
zása egyaránt egyszerű. Mivel alapszintű e-mail szol- 
gáltatásokat is biztosít, azoknak a felhasználóknak is 
hagyhatunk magánüzeneteket, akik éppen nincsenek 
bejelentkezve. Aki a NexusChat kipróbálása mellett 
dönt, feltétlenül látogasson el a program weboldalára is, 
ahol megtalálja szolgáltatásainak teljes listáját (lásd az 
internetes forrásokat). 

Míg Francois újratölti a poharakat, nézzünk egy másik 
BBS-es példát. Vannak programok, melyek jóval több lehe- 
tőséget kínálnak, mint a NexusChat, például teljes értékű 
üzenetkezelést, összetettebb szobalétrehozást — külön szo- 
bákat az üzenetek továbbítására és a csevegésre -—, statiszti- 
kák készítését, világórát, naptárat stb. Ilyen például 

a Walter de Jong által fejlesztett bbs100. 

A bbs100-at forrásból kell lefordítanunk, amit viszont 

a bbs100 webhelyéről tölthetünk le (lásd a forrásokat). 

A fordítás és a telepítés menete egyszerű, bár a lépések 
kissé furcsának tűnhetnek: 


tar -xzvf bbs100-2.1.tar.gz 

cd bbs100-2.1/src 

. /configure -prefix-/home/bbs100 
make dep 

make 

make install 











A fenti prefix kapcsolóra külön fel szeretném hívni 

a figyelmet. Fontos, hogy ne az alapértelmezett /usr/local 
könyvtárat használjuk, mert a BBS-nek írási jogra van 
szüksége a megadott könyvtárhoz, ami a /usr/local eseté- 
ben erősen kérdéses. A make instal1] parancsot nem 
rootként futtattam, ugyanis erre semmi szükség. 
Természetesen ilyenkor ellenőriznünk kell, hogy van-e 
írási jogunk arra a könyvtárra, ahová a telepítést el 
szeretnénk végezni. Nálam ez a BBS a /home/bbs100 
könyvtárba került. 

Ha túljutottunk a telepítésen, váltsunk át a telepítési 
könyvtárba (esetemben ez a /home/bbs100), majd kedvenc 
szövegszerkesztőnkben nyissuk meg az etc/param fájlt. 
Néhány beállítást azonnal írjunk is át, ilyen például a BBS 
neve, a csatlakozások fogadására használt kapu száma és 
a telepítési könyvtár: 


bbs name A pince 
port number 12345 
basedir /home/bbs100 


Mielőtt továbblépnénk, röviden ismerkedjünk meg az etc 
könyvtárban található egyéb fájlokkal. Találunk köztük üd- 
vözlőképernyőt, napi üzenetet, súgófájlokat, rendszersza- 
bályokat, amelyek az első bejelentkezésnél jelennek meg, 
valamint számos további érdekességet. 

Már majdnem végeztünk! Mivel Francois lett a rend- 
szergazda, valamilyen jelszót kell adnunk neki. 

A BBS telepítési könyvtárában adjuk ki a bin/mkpasswd 
rendszergazda neve parancsot; ezt követően meg kell 
adnunk a kívánt jelszót: 


bin/mkpasswd Francois 

bbs100 2.1 mkpasswd by Walter de Jong 
cAwalter(Gheiho.net: (C) 2004 

Enter password: 

Enter it again (for verification): 
OIGXUTXGDPUTOWZW2AgMXZRkCNk 


Az utolsó sor tartalmazza a rendszergazda titkosított jelsza- 
vát. Ez közölnünk kell a BBS-sel, tehát nyissuk meg az 
etc/su passwd fájlt, írjuk be a rendszergazda nevét, majd 
egy vesszővel elválasztva a fenti titkosított jelszót: 


Francois : OIGXutXGPUTOWZw2AgMXZRkCNk 


A BBS elindítása a /home/bbs100/bin/bbs start paranccsal 
történik. Ha már fut a démon, telnet-tel, a megadott kapun 
keresztül csatlakozhatunk hozzá: 


telnet kiszolgáló 12345 


A rendszergazda (superuser, root, ha úgy tetszik) BBS-es 
megfelelőjére, vagyis a SysOp-ra (system operator, rend- 
szeroperátor) a $ gyorsbillentyűvel lehet átváltani. A gyors- 
billentyűt csak azok a felhasználók érhetik el, akiknek a ne- 
ve szerepel a etc/su passwd fájlban, egyébként egy csinos, 
a Föld különféle pontjain érvényes időt mutató naptár jele- 
nik meg. Miután átváltottunk a SysOpra, jó néhány további 
parancsot is el tudunk érni. A SysOP menübe a CTRL-4-S 
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billentyűkombinációval léphetünk be. A SysOpnak joga 
van a rendszerbeállítások módosítására, üzenettovábbító 

és csevegőszobák létrehozására, valamint szükség esetén 

le tudja rendezni a kellemetlenkedő felhasználókat is. 

Bár kell egy kis idő, mire megszokjuk őket, a BBS-ek 
mégis sokoldalúak, könnyen megszerethetők. Nézzünk 
egy másik szempontot is: hat aktív felhasználóval nálam 
a memóriahasználat — a bbs100 program memóriaigényét 
is figyelembe véve — 66917 bájt volt. Mint láthatjátok, 

mes amis, a kis méretnek és az egyszerűségnek is megvan 
a maga előnye. 

Miközben csodálattal adózunk az azonnali és a mobiltelefo- 
nos üzenetküldés népszerűsége előtt, egy pillanatra jusson 
eszünkbe, hogy milyen régre nyúlnak ezeknek a szolgálta- 
tásoknak a gyökerei. Példaként egy réges-régi szolgáltatást 
szeretnék felidézni: annak idején sokat játszottunk a write 
és a mesg nevű paranccsal. A mesg segítségével lehet bekap- 
csolni az üzenetkezelő rendszert: 
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mesg y 


Ezzel gyakorlatilag engedélyeztük másoknak, hogy üzene- 
teket küldjenek nekünk. Most jelentkezzünk be a másik 
terminálon is, és szintén engedélyezzük az üzenetküldést. 
Tegyük fel, hogy marce1 névvel bejelentkeztem az egyik 
terminálon, míg Francois egy másikon dolgozik. Ha cseveg- 
ni akar velem, a következő parancsot kell kiadnia: 


write marcel /dev/pts/16 


Ezután begépelheti, amit közölni akar velem. A kapcsolat 
lezárására a CTRL-D billentyűkombináció szolgál. Nálam 
a következő szöveg jelent meg: 


[marceldfrancois marce1]$ 

Message from francoisdfrancois.salmar.com on 
pts/14 at 19:30 ... 

Helló, főnök! 

Eldöntötted már, hogy ma este milyen bort 
s szolgáljunk fel? 


Ahogy a mondás tartja: Plus ca change, plus cfest 

la méme chose. 

Úgy tűnik, mes amis, ismét ránk esteledett. Lassan fejezzétek 
be a beszélgetést. Persze csak kényelmesen, ebben a világban 
oly könnyű és jó hátradőlni és kapkodás nélkül kortyolgatni 
egy pohárka bort. Azt mondom tehát, igyunk egymás egész- 
ségére, mes amis! A votre santé! Bon appétit! 


Linux Journal 2005. június, 134. szám 


A cikkhez tartozó források elérhetősége: 
5 www.linuxjournal.comjarticle/8198 


Marcel Gagné (mggagneOsalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában tavaly szep- 
temberben megjelent Linux-rendszerfelügyelet 
(ISBN 96-9301-40) című könyvnek. 
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Betőörések, betörési kísérletek II. 


avagy ki nevet a végén? 


A sorozat előző tagjából megtudhattuk, pontosan milyen következményekkel 
jár az, ha valaki egy számítógépét vagy számítástechnikai rendszerét megpróbál 
feltörni. Most azokról a (jogijeszközökről lesz szó, melyekkel egy ilyen csibészt 


(ckrackert) nyakon lehet csípni. 


,Számítástechnikai rendszer minden olyan berendezés, amely 
közvetlen emberi beavatkozás nélkül (automatikusan) végez 
adatfeldolgozást, azaz adatok bevitelét, kezelését, tárolását, 
továbbítását látja el. A számítástechnikai rendszerek körébe 
tartoznak a számítástechnikai adatfeldolgozásra épülő, me- 
móriával rendelkező olyan egységek is, amelyek megjelené- 
sükben nem hagyományos számítógépet jelentenek. 

A számítástechnikai rendszer fogalma azonban nemcsak az 
egyes berendezésekre terjed ki, hanem felöleli az azok összekap- 
csolása révén létrejött hálózatot, valamint az adattovábbítást, 
a kapcsolatfelvételt biztosító műszaki berendezéseket is." " 


indenek előtt nem árt definiálni, hogy 
mit is ért a jog számítástechnikai rendszer 
alatt: 


Ennek értelmében, ha mondjuk pár év múlva valaki 
betörve az intelligens hűtőszekrényembe rendel nekem 

15 karton tejet, pontosan ugyanezt a bűncselekményt fogja 
elkövetni — feltéve persze, hogy addig nem változtatják 
meg a tényállás elemeket. 


A betörés felfedezése 

Függetlenül attól, hogy az elkövető a rendszerünkbe belép- 
ve milyen mértékű kárt okoz, azzal, hogy a rendszert feltör- 
te, már megvalósította a számítástechnikai rendszer elleni 
bűncselekmény tényállásának valamennyi elemét. Feltétel 
persze, hogy a rendszerünknek legyen legalább valamilyen 
minimális szintű védelme (hardver- vagy szoftver-alapú 
tűzfal), hogy azt jogosulatlan belépéssel, kijátszással vagy 
más módon meg lehessen sérteni. 


Alapszint 
Rendszergazdaként belépve azt tapasztaljuk, hogy valaki 
az éj vagy a bitek leple alatt bejutott a rendszerünkbe, és 


! Complex CDJogtár Btk. 300/F§ Kommentár részlet. 
: Linuxos rendszerben ennek is marad nyoma, windows használata 
esetén pedig tételezzük fel, hogy így tett. 
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tallózta a könyvtárainkat.? Annak nincs nyoma, hogy bár- 
miféle változtatást eszközölt volna, vagy adatokat másolt 
volna le. Ilyenkor az eljárás, (azt követően, hogy a rendsze- 
rünket újra biztonságossá tettük például másik típusú tűz- 
fal telepítése, trójai kereső program lefuttatása... stb.) hogy 
a korábban már begyűjtött naplóbejegyzéseket, illetve 

a visszakereshető ip címet lementjük (lehetőleg egy olyan 
gépre, ami nincs hálózatra kötve, hogy esetleg a visszatérő 
garázda ne leljen rá). 

Az e módon kigyűjtött információkat — egy ismeretlen tet- 
tes elleni feljelentés keretében - eljuttathatjuk az illetékes 
ügyészhez vagy nyomozóhatósághoz. 


Középszint 

A betörő jogosulatlanul belépett, jelenleg is bent tartózko- 
dik, és éppen a szupertitkos feliratú mappánk tartalmát pró- 
bálja meg letölteni. A probléma leggyorsabb megoldásaként 
válasszuk le a gépet a netről. Ez esetben az elkövető észre 
fogja venni, hogy jelenlétére felfigyeltek, és talán soha töb- 
bé nem próbálkozik meg a rendszerünkkel. 

Ha a szupertitkos felirat azonban csak mindenféle kacatot 
rejtett, melyeket épp csalinak helyeztünk el ezen a gépen, 
akkor a helyzet persze merőben más. Amennyiben a ren- 
delkezésünkre álló adatok alapján megtudtuk az elkövető 
ip címét, megkereshetjük a cím szolgáltatóját, és megkér- 
dezhetjük, az előfizető nevét. Ezzel akár a későbbiekben 
eljáró nyomozó hatóság munkáját is segíthetjük, hiszen 
ebben az esetben már nem ismeretlen tettes ellen kell 
nyomozást folytatniuk. 

Fontos tudni, hogy a párbajok ideje a XIX. századdal lejárt, 
nem megoldás az, ha a betörő kilétének felderítése érdeké- 
ben mi is megpróbáljuk feltörni a minket ostromló rendsze- 
rét, hiszen akkor ugyanúgy jogosulatlan belépésre teszünk 
kísérletet vagy adott esetben, ha az akció célravezető, mi 

is elkövetővé válunk. Figyelemmel arra, hogy a Büntető 











törvénykönyv nem nevesíti a , hirtelen felindulásból elkö- 
vetett számítástechnikai rendszer védelmét biztosító techni- 
kai rendszer kijátszását, mint tényállást — így e bűncselek- 
mény elkövetésénél az erős felindulás kevéssé 
beszámítható. Jelen feltételek mellett nem értel- 
mezhető jogos védelemként az sem, ha 
a büszkeségében sértett rendszergazda 
bosszút áll. 

A nyomozóhatóságnak azonban 

— szemben a haragos rendszergaz- 
dával - lehetősége van rá, hogy 
külön engedély keretében titkos 
adatszerzést végezzen, ennek 
érdekében meghatározott számí- 
tástechnikai rendszer védelmét 
biztosító technikai intézkedése- 
ket kijátsszon. 


Hajjaj" szint 

Az elkövető belépve a gépünk- 
re — azon kívül, hogy garázdál- 
kodott az adataink között, — 
megnyitott pár portot, melyeken 
át a mi gépünk ip címét használ- 
va ostromol már hálózatokat. 

Ez az eset mind közül a legsúlyo- 
sabb, itt mindenképpen javasolt az 
internetszolgáltatók (a kiderített IP- 
cím szolgáltatója csakúgy, mint a saját 
szolgáltatónk) valamint a rendőrség 
értesítése. 

Itt különösen nagy gondot kell fordítanunk 
arra, hogy a betörés körülményeit a lehető leg- 
precízebben dokumentáljuk (Adott esetben tanúk 
jelenlétében készített jegyzőkönyvekkel, melyeket 

a betöréssel kapcsolatosan tudtunkra jutott információ- 
hoz mellékelünk.) 


Miért van mindez? 

1. Értesíteni kell a betörő ip címét adó szolgáltatót 
a betörés körülményeiről is, hogy adott esetben 
saját hálózatán belül megpróbálhassa visszakeresni 
az elkövetőt. 


2. Értesíteni kell a saját szolgáltatónkat, illetve azokat 
a szolgáltatókat akik felé a gépünkről kísérletet indítot- 
tak, hogy felhívhassák ügyfeleik figyelmét a veszélyre. 


3. Értesíteni kell a rendőrséget, mert jó eséllyel előfordul- 
hat, hogy a tőlünk indított kísérletet valaki más bejelenti 
az ügyészségen vagy a nyomozóhatóságnál, elkövető- 
ként a mi ip címünket jelölve meg. 


A feljelentés sorsa 

A feljelentést elsődlegesen nyilvántartásba veszik. Megvizs- 
gálják, hogy a történeti tényállás bűncselekmény gyanújának 
megállapítására alkalmas-e, a büntetőeljárás megindításának 
van-e akadálya, szükséges-e halaszthatatlan nyomozási cse- 
lekmény vagy más intézkedés foganatosítása, a bűncselek- 
mény nyomozására van-e hatásköre, illetékessége. 


www.linuxvilag.hu 


A nyomozó szerv a Büntető eljárásról szóló törvény szerint 
köteles már a feljelentés vételekor, illetőleg a nyomozó 
szerv tagjának észlelésekor — ha a késedelem veszéllyel 























jár, a jegyzőkönyv felvétele előtt is — minden olyan 
intézkedést megtenni, amely a nyomozás ered- 
ményességét, gyors teljesítését elősegíti. 
Például amennyiben a betörés észlelé- 
sekor és bejelentésekor az elkövető 
a rendszerben tartózkodik, és 
tettenérhető, helye lehet azonnali 
házkutatásnak. Indokolt lehet 
ezen , gyorsított eljárás" azért is, 
mert ennek későbbi elvégzése 
az eljárás eredményességét 
károsan befolyásolhatja. 
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Lefoglalás 
A lefoglalás jogászi nyelven: 
a bizonyítás érdekében a dolog 
birtokának elvonása a birtokos 
rendelkezése alól. Külön érde- 
kes részlet, hogy a lefoglalás 
kapcsán a törvény már külön 
nevesíti a számítástechnikai 
rendszernek vagy ilyen rendszer 
útján rögzített adatokat tartalmazó 
adathordozónak a lefoglalását. 
Elrendelésére a bíróság, az ügyész 
és a nyomozóhatóság jogosult, 
többek között akkor, ha az adott tárgy 
bizonyítási eszköz. 
A lefoglalás menete a következő: először is 
a rendszer vagy adathordozó birtokosát illetve 
az adat kezelőjét fel kell szólítani, hogy a keresett dolgot 
adja át, illetőleg a számítástechnikai rendszer útján rögzí- 
tett adatot tegye hozzáférhetővé. (Tehát a nyomozóható- 
ság az internetszolgáltatót is kötelezheti valamennyi általa 
ismert információ kiadására). Amennyiben ezt önként 
nem teszi meg, rendbírsággal (általában 1000-200.000 fo- 
rint közötti összeg) sújtható, kivéve a terheltet és azt, aki 
a tanúvallomást megtagadhatja, illetőleg aki tanúként nem 
hallgatható ki. (Iehát ha az elkövető takarítónőjét találják 
otthon a házkutatásra érkező rendőrök, aki makacs mó- 
don nem akarja átadni a gépét, rá kiszabhatnak rendbír- 
ságot, de ha maga az cracker van jelen, akkor ő, mint 
terheltet nem lehet megbírságolni). Fontos azonban tudni, 
hogy az átadás megtagadása egyik esetben sem lesz 
akadálya annak, hogy a keresett dolgot, illetőleg a számí- 
tástechnikai rendszer útján rögzített adatot házkutatással, 
illetve motozással megszerezzék. 
A nyomozást általában annak megindulását követő 2 hóna- 
pon belül befejezik. Ez alatt az idő alatt vagy lehull a lepel 
vagy a tettes örökre ismeretlen marad. 


Dr. Dudás Ágnes (dudas.agnes(dabend.hu) 
ügyvédjelölt, az FSF egyik aktivistája. 2004-ben 
végzett az ELTE Jogtudományi Karán. Szakdol- 
gozatát a szoftverek szerzői jogi védelméről 
írta, a 2003-as évet pedig e terület kutatásával 
a berlini Humboldt Egyetemen töltötte. 
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